Re: recv function
From: saxxyb (saxxyb_at_discussions.microsoft.com)
Date: 01/17/05
- Next message: Randolph Neall: "Cable modem/router causes error 10054, "Connection was forcibly reset by remote host""
- Previous message: saxxyb: "Re: recv function"
- In reply to: Alun Jones [MSFT]: "Re: recv function"
- Next in thread: Arkady Frenkel: "Re: recv function"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 17 Jan 2005 15:53:05 -0800
Hi,
nleft = nbytes, sorry about the typo.
That function, was not written by me, by the way :)
Very good points , here is an e-mail that I sent to my partners:
/-----------------------------------------------------
Hi,
A possible fix; I have the spectrum function and readn function that Chris
B has below, and then explanation follows :
>From AcqSystem.cpp
BOOL CAcqSystem::GetSpectrum(int* pResult)
{
char szMessage[100];
if (!m_bSocketConnected)
{
*pResult = ACQ_ERR_SOCKET_DISCONNECTED;
return false;
}
m_cabinRequest.dwparam1 = 0;
m_cabinRequest.command=REQUEST_SPECTRUM;
send(m_destSocket,(char
*)&m_cabinRequest,sizeof(m_cabinRequest),NO_FLAGS_SET); // request current
histogram buffer
if (readn(m_destSocket,(char *)&m_cabinRequest,sizeof(m_cabinRequest))
== SOCKET_ERROR)
{
// display error message
wsprintf(szMessage,"Windows Socket error %d: Error while receiving N
data.",WSAGetLastError());
::MessageBox(NULL, szMessage,"Windows Sockets Error",MB_OK);
*pResult = ACQ_ERR_SOCKET_READ;
return false;
}
if (readn(m_destSocket,(char *)&m_SpecData,sizeof(m_SpecData)) ==
SOCKET_ERROR)
{
// display error message
wsprintf(szMessage,"Windows Socket error %d: Error while receiving N
data.",WSAGetLastError());
::MessageBox(NULL, szMessage,"Windows Sockets Error",MB_OK);
*pResult = ACQ_ERR_SOCKET_READ;
return false;
}
*pResult = ACQ_SUCCESS;
return true;
}
int CAcqSystem::readn(SOCKET sfd, char FAR *buffer, long nbytes)
{
//if (!m_bSocketConnected) return false;
int nleft;
int nread;
nleft=(int)nbytes;
while (nleft > 0)
{
nread=recv(sfd,(char FAR *)buffer,1000,NO_FLAGS_SET);
if (nread < 0) // Handle Socket Error
{
//MessageBox(NULL,"nread<0","Debug",MB_OK);
return(nread);
}
else if (nread == 0)
break;
nleft -= nread;
(char *)buffer += nread;
}
return ((int)(nbytes-nleft));
}
As you can see, from the first function, there is one request and 2 replies.
This software runs well for at most 2.5 hours, it will either crash at 2.5
hour mark or sometime before. From the debug files I created I found that in
one of those seconds when windows sends a request, QNX sends the first reply
and the second reply faster than windows can read, the struct m_cabinRequest
is about 298 bytes, and Chris B has set the buffer max to 1000 for one
receive (in a loop as can be seen above), so in that one second that QNX
sends it faster than windows it goes to read the first request, and even
though the struct is only 298 bytes, because Chris B has set it to 1000, it
will also read a little bit of the second reply because QNX is faster or
Windows is slower, however you want to look at it. I think that the send and
recv functions should be together, meaning that the QNX implementation of
GetSpectrum should only have one send and one receiver, this will greatly
diminish, and I think, make the probability of timing problems near 0.
Obviously you know what happens in a send and receive, so you’d understand
why this probability of timing problems will go to zero.
The other reason for this is because windows and QNX are not synchronized,
meaning windows and QNX are not in lockstep in their timing, so windows could
be slower than QNX, and this scenario does happen, because it shows in the
following log file :
//From Log file of the above readn function
Nleft = 298
Before READN
AFTER READN
Nleft = -702
END OF FUNCTION
Nleft = 4156
Before READN
AFTER READN
Nleft = 3696
Before READN
AFTER READN
Nleft = 2696
Before READN
AFTER READN
Nleft = 1938
Before READN
AFTER READN
Nleft = 938
Before READN
AFTER READN
Nleft = 702
Before READN
The first line is the first reply that is a result of the send that the
GetSpectrum function sends, and as you can see, after it reads from the
socket it reads more than 298 bytes, it reads 1000 bytes (this is reading
into m_cabinRequest struct), and then it proceeds to read the spectra, and
hangs on the last 702 bytes, because it has read all of the bytes in the
stream. QNX is sending faster than Windows in that one second (Because 2
replies without an intervening send). This really proves that someone needs
to either change QNX code to have a send and receive and then another send
and receive, or just one send and receive, since the first receive is really
useless, and is only for debugging.
The Send and Receive functions act like lockstep because you know that one
is waiting for the other, so the timing problem goes away.
I have come up with a work around, I’ll see if it works, I took Chris B’s
code, and instead of the 1000 he has got in the recv function, I put the
nbytes that is passed into the function. And the reason this works is
because of the fact that even if the first reply is made, and second is made
faster than windows, windows will only read 298 of them ,and the next receive
statement will pickup the spectral things. It has been running for 10900
seconds, but I’d like to do more tests, to see if it is stable. It has been
running in Vince’s office… I think that this problem can be band aided with
windows programming, so no need to alter QNX code, but the above reasons are
the cause.
-Thanks
"Alun Jones [MSFT]" wrote:
> Okay, let's see if I can express what I'm getting at:
>
>
> > readn(SOCKET sfd, char FAR* buffer, long nbytes )
> > {
> > long nleft;
> > int nread;
> >
> > nleft = nread;
>
> What is the value of nread? Technically, it's random - and now you're
> setting nleft to that value, too. If I presume that you meant "nleft =
> nbytes;" there, let's keep on going. nleft is now 5.
>
> > while(nleft >0)
> > {
> > nread = recv(sfd, (char FAR *) buffer, 1000, NO_FLAGS_SET);
>
> Okay, so we've now put 1000 bytes into buffer. But we only called readn()
> with nbytes set to 5. How big was our buffer? There's no check to see that
> buffer has enough space for more bytes than asked for, and someone writing
> that code (maybe you in another six months) will assume that the buffer size
> need only be as large as the data you're asking for. You have just
> overflowed a buffer, causing (at best) a crash, and (at worst) a hacker to
> take over the machine.
>
> nread is now set to 1000.
>
> > if(nread < 0)
> > return nread;
>
> Instead of checking return values against "<0", you should really be
> checking the return values as documented. Check to see if the value of
> SOCKET_ERROR has been returned. It's not going to bite you this time, but
> some of the socket functions return unsigned values, that will not ever be
> less than 0 - but they may be equal to SOCKET_ERROR.
>
> > else if(nread == 0)
> > break;
> > nleft -= (long) nread;
> > (char *)buffer += nread;
> > }
> >
> > return ((int)(nbytes - nleft));
> > }
>
> So, now this function returns 1000, which is way more than you asked for.
> It therefore requires the caller to be aware of its internal semantics, that
> it will ask for bytes a thousand at a time, will almost always ask for more
> than requested, and will almost always overflow a buffer that is sized for
> the data you expect.
>
> Code defensively - always assume that the person calling your code can make
> no assumptions about what your code actually does, and only knows the
> interface and any other documentation you provide on that function.
>
> Alun.
> ~~~~
> --
> Software Design Engineer, Internet Information Server (FTP)
> This posting is provided "AS IS" with no warranties, and confers no rights.
> "saxxyb" <saxxyb@discussions.microsoft.com> wrote in message
> news:19AF8D99-ACE7-4B55-A70B-871CF1A59564@microsoft.com...
> > Hi,
> >
> > Yes... Because it is in a loop, and nread holds the value that has been
> > returned by read stmt. I am reading everything in that buffer, because I
> > need
> > them, they fill my struct up.. Take a look at the code again.
> >
> >
> > Thanks
> >
> > "Alun Jones [MSFT]" wrote:
> >
> >> Really?
> >>
> >> Apart from the assignment "nleft=nread", which assigns one variable the
> >> value of another uninitialised variable, imagine that you've called this
> >> function asking for five bytes, and the receive buffer has a thousand
> >> available to you.
> >>
> >> Pretend you are the computer, and step through the code.
> >>
> >> Alun.
> >> ~~~~
> >> --
> >> Software Design Engineer, Internet Information Server (FTP)
> >> This posting is provided "AS IS" with no warranties, and confers no
> >> rights.
> >>
> >> "saxxyb" <saxxyb@discussions.microsoft.com> wrote in message
> >> news:2284B845-FC5E-48EA-8EEE-EA65C1DFA550@microsoft.com...
> >> >I am not thowing them away.. I am using all of the bytes...
> >> >
> >> > "Alun Jones [MSFT]" wrote:
> >> >
> >> >> Sure. 1.
> >> >>
> >> >> You need to realise that recv() will give you as many bytes as are
> >> >> currently
> >> >> buffered, up to the number of bytes that you ask for.
> >> >>
> >> >> If there are no bytes buffered, it will block if the socket is
> >> >> blocking.
> >> >>
> >> >> You are reading bytes from that buffer and throwing them away. That's
> >> >> not
> >> >> safe. If you read bytes from the read buffer, but don't use them, you
> >> >> need
> >> >> to hang onto them for the next read.
> >> >>
> >> >> Alun.
> >> >> ~~~~
> >> >> --
> >> >> Software Design Engineer, Internet Information Server (FTP)
> >> >> This posting is provided "AS IS" with no warranties, and confers no
> >> >> rights.
> >> >>
> >> >> "saxxyb" <saxxyb@discussions.microsoft.com> wrote in message
> >> >> news:714F4A42-16BE-46FA-97E9-DE21DAE04B54@microsoft.com...
> >> >> > Hi,
> >> >> >
> >> >> > But there is a lower bound right ?
> >> >> >
> >> >> > -Thanks
> >> >> >
> >> >> > "Arkady Frenkel" wrote:
> >> >> >
> >> >> >> You have to keep in mind that TCP is stream protocol and if
> >> >> >> connection
> >> >> >> is Ethernet MTU is 1500 bytes so that max packet send on lan and
> >> >> >> TCP
> >> >> >> stack
> >> >> >> join such packets to produce single data block which sender TCP
> >> >> >> stack
> >> >> >> divided before send, so you really can't know how many bytes recv()
> >> >> >> will
> >> >> >> return and need to check some application delimiters or length
> >> >> >> parameter
> >> >> >> you
> >> >> >> set inside data to check that.
> >> >> >> Arkady
> >> >> >>
> >> >> >> "saxxyb" <saxxyb@discussions.microsoft.com> wrote in message
> >> >> >> news:F88DC2D9-7E81-4EB0-8BE6-35E98A523F8C@microsoft.com...
> >> >> >> > Hi,
> >> >> >> >
> >> >> >> > There is an ontimer function, that is a separate thread, our
> >> >> >> > problem
> >> >> >> > is
> >> >> >> > somewhat unique, just want to put the solution out here if there
> >> >> >> > are
> >> >> >> others
> >> >> >> > that might come across this :
> >> >> >> >
> >> >> >> > We have 2 systems one running windows and another runing QNX
> >> >> >> > realtime
> >> >> >> > OS.
> >> >> >> > The realtime OS asks the various detectors for date every second
> >> >> >> > and
> >> >> >> records,
> >> >> >> > adn also asks for spectra every x seconds, and that x is set in
> >> >> >> > the
> >> >> >> software,
> >> >> >> > x is in seconds. Windows and QNX talk via sockets, and use http
> >> >> >> > protocol
> >> >> >> to
> >> >> >> > talk. Recv function is a blocking receive. So, basically they
> >> >> >> > talk
> >> >> >> > with
> >> >> >> > send and receives. There are 2 primary functions, GetAcqData and
> >> >> >> > GetSpectrum. GetAcqData just gets the second by second data that
> >> >> >> > the
> >> >> >> > detectors have, and GetSpectrum gets the spectrum if the time
> >> >> >> > interval
> >> >> >> > is
> >> >> >> > met. The GetAqData deals with a struct that is 298 bytes in
> >> >> >> > lenght
> >> >> >> > and
> >> >> >> > GetSpectrum deals with struct that is 4156 bytes. The transfer is
> >> >> >> > done
> >> >> >> > by
> >> >> >> > byte transfer, so basically Windows asks QNX for something and QN
> >> >> >> > responds
> >> >> >> > with 298 bytes and windows reads 298 bytes. Basically the
> >> >> >> > function
> >> >> >> > definition of GetAcqData is a send and a reply, Windows reads
> >> >> >> > reply
> >> >> >> > via
> >> >> >> the
> >> >> >> > readn function :
> >> >> >> >
> >> >> >> > readn(SOCKET sfd, char FAR* buffer, long nbytes )
> >> >> >> > {
> >> >> >> > long nleft;
> >> >> >> > int nread;
> >> >> >> >
> >> >> >> > nleft = nread;
> >> >> >> >
> >> >> >> > while(nleft >0)
> >> >> >> > {
> >> >> >> > nread = rev(sfd, (char FAR *) buffer, 1000, NO_FLAGS_SET);
> >> >> >> > if(nread < 0)
> >> >> >> > return nread;
> >> >> >> > else if(nread == 0)
> >> >> >> > break;
> >> >> >> > nleft -= (long) nread;
> >> >> >> > (char *)buffer += nread;
> >> >> >> > }
> >> >> >> >
> >> >> >> > return ((int)(nbytes - nleft));
> >> >> >> > }
> >> >> >> >
> >> >> >> > Now, the GetSpectrum has an interesting definition, it has a send
> >> >> >> > ,
> >> >> >> > and
> >> >> >> > 2
> >> >> >> > receives, because QNX will send it two responses, one with the
> >> >> >> > 298
> >> >> >> > bytes
> >> >> >> and
> >> >> >> > the next is 4156, I disagree with this, because it throws out the
> >> >> >> > security
> >> >> >> > that send and receive gives. This introduces potential timing
> >> >> >> > issues,
> >> >> >> > as
> >> >> >> QNX
> >> >> >> > and windows are not in lockstep, but QNX internally has all
> >> >> >> > detectors
> >> >> >> timed
> >> >> >> > with the GPS. The problem in the program that would cause it to
> >> >> >> > lock
> >> >> >> > up
> >> >> >> > occurred when QNX was faster than Windows, and because of the
> >> >> >> > nature
> >> >> >> > of
> >> >> >> the
> >> >> >> > readn function there would be mismatches as to the stucts.
> >> >> >> >
> >> >> >> > So, here goes we leave this program runnign and every second it
> >> >> >> > asks
> >> >> >> > for
> >> >> >> > GetAcqData and Getspectrum, just constantly, in one of those
> >> >> >> > seonds
> >> >> >> > QNX
> >> >> >> > is
> >> >> >> > faster than Windows, in the GetSpectrum function there is a send
> >> >> >> > from
> >> >> >> > windows, and QNX quickly sends its two responses before Windows
> >> >> >> > has
> >> >> >> > chance
> >> >> >> to
> >> >> >> > read, so WIndows goes and reads, and even though the first struct
> >> >> >> > is
> >> >> >> > only
> >> >> >> 298
> >> >> >> > bytes, because it is a pointer and the bytes in the receive is a
> >> >> >> > 1000,
> >> >> >> > and
> >> >> >> > since QNX was fast and there is now 298 + 4156 windows does not
> >> >> >> > just
> >> >> >> > read
> >> >> >> 298
> >> >> >> > it reads 1000, keep in mind this is the first read, and it is
> >> >> >> > only
> >> >> >> > suppose
> >> >> >> to
> >> >> >> > read 298 bytes, and then second read, it thinks that there 4156
> >> >> >> > and
> >> >> >> > does
> >> >> >> not
> >> >> >> > know that 702 ytes has been read, so it reads until it gets to
> >> >> >> > 702
> >> >> >> > and
> >> >> >> locks
> >> >> >> > up becuase it has read it all.
> >> >> >> >
> >> >> >> > The real fix would be for QNX guys to go in and make the
> >> >> >> > GetSpectrum
> >> >> >> > function one send and receive or 2 series of sends and receives,
> >> >> >> > so
> >> >> >> > :
> >> >> >> >
> >> >> >> > Send
> >> >> >> > Receive 298
> >> >> >> > Send
> >> >> >> > Receive 4156
> >> >> >> >
> >> >> >> > Because this would eliminate the timing problem obviously.
> >> >> >> >
> >> >> >> > But they do not want to touch the QNX... So, I came up with a
> >> >> >> > workaround,
> >> >> >> > lets bing back that function readn and I will replate the 1000
> >> >> >> > and
> >> >> >> > put
> >> >> >> > it
> >> >> >> in
> >> >> >> > bytes of the struct that is expected to read, and change the
> >> >> >> > longs
> >> >> >> > to
> >> >> >> ints.
> >> >> >> > This will ensure no problems unless the receive reads less than
> >> >> >> > 298
> >> >> >> > bytes.
> >> >> >> > This will work beause even if QNX is faster than windows, we are
> >> >> >> > ony
> >> >> >> > going
> >> >> >> to
> >> >> >> > read 298 bytes and that is it, and from what I have seen it does
> >> >> >> > not
> >> >> >> > read
> >> >> >> > less than that, and then the second read will read 4156 and if it
> >> >> >> > gets
> >> >> >> less
> >> >> >> > than it is fine because of the loop.
> >> >> >> > Took a long time lots of printf statements... When I left the
> >> >> >> > program
> >> >> >> > had
> >> >> >> > been running for 4 hours, so lets see if it runs tomorrow !
> >> >> >> >
> >> >> >> >
> >> >> >> > -Thanks
> >> >> >> >
> >> >> >> > "Alexander Nickolov" wrote:
> >> >> >> >
> >> >> >> > > Actually, the first step should be for you to remove that
> >> >> >> > > socket code from the GUI thread. It's not a good idea
> >> >> >> > > to perform potentially blocking calls on a GUI thread.
> >> >> >> > > Spawn a worker thread and do the blocking socket
> >> >> >> > > I/O there. Then all you need to do is clear a variable
> >> >> >> > > each time you read data from the socket. Your timer
> >> >> >> > > on the main thread will increment it each second and
> >> >> >> > > after it reaches your timeout threshold close the socket.
> >> >> >> > > You'll need synchronization for the variable of course
> >> >> >> > > (for example use the InterlockedXXX family of functions).
> >> >> >> > > Ah, I assume you are familiar with SetTimer/KillTimer/
> >> >> >> > > WM_TIMER?
> >> >> >> > >
> >> >> >> > > --
> >> >> >> > > =====================================
> >> >> >> > > Alexander Nickolov
> >> >> >> > > Microsoft MVP [VC], MCSD
> >> >> >> > > email: agnickolov@mvps.org
> >> >> >> > > MVP VC FAQ: http://www.mvps.org/vcfaq
> >> >> >> > > =====================================
> >> >> >> > > "saxxyb" <saxxyb@discussions.microsoft.com> wrote in message
> >> >> >> > > news:CB306147-6B5C-4316-AF15-204DD54AF163@microsoft.com...
> >> >> >> > > > It is blocking by default right ?... I was wondering if it is
> >> >> >> > > > a
> >> >> >> > > > memory
> >> >> >> > > > issue,
> >> >> >> > > > beause it takes so long to crash, I mean the window just
> >> >> >> > > > freezes.
> >> >> >> > > > How
> >> >> >> do
> >> >> >> > > > I
> >> >> >> > > > set that timer you suggested ?
> >> >> >> > > >
> >> >> >> > > >
> >> >> >> > > > "Arkady Frenkel" wrote:
> >> >> >> > > >
> >> >> >> > > >> OTOH that really important if you use blocked or non-blocked
> >> >> >> > > >> socket
> >> >> >> > > >> Arkady
> >> >> >> > > >>
> >> >> >> > > >> "Alexander Nickolov" <agnickolov@mvps.org> wrote in message
> >> >> >> > > >> news:#v1EGqU9EHA.3504@TK2MSFTNGP12.phx.gbl...
> >> >> >> > > >> > Verify it with a network sniffer like Ethereal.
> >> >> >> > > >> >
> >> >> >> > > >> > --
> >> >> >> > > >> > =====================================
> >> >> >> > > >> > Alexander Nickolov
> >> >> >> > > >> > Microsoft MVP [VC], MCSD
> >> >> >> > > >> > email: agnickolov@mvps.org
> >> >> >> > > >> > MVP VC FAQ: http://www.mvps.org/vcfaq
> >> >> >> > > >> > =====================================
> >> >> >> > > >> > "saxxyb" <saxxyb@discussions.microsoft.com> wrote in
> >> >> >> > > >> > message
> >> >> >> > > >> > news:38E89DC1-4FD3-4551-BFCB-BA7F28CF87D3@microsoft.com...
> >> >> >> > > >> > > HI,
> >> >> >> > > >> > >
> >> >> >> > > >> > > I highly doubt it is that, because the request and
> >> >> >> > > >> > > response
> >> >> >> structs
> >> >> >> > > >> > > are
> >> >> >> > > >> of
> >> >> >> > > >> > > same length, and every second it requests two things, it
> >> >> >> > > >> > > is
> >> >> >> > > >> > > only
> >> >> >> > > >> > > after a
> >> >> >> > > >> > > certain amoutn of time that it fails. So, we have a QNX
> >> >> >> > > >> > > side
> >> >> >> > > >> > > and
> >> >> >> a
> >> >> >> > > >> > > Windows
> >> >> >> > > >> > > side, when windows is expecting a certain struct, the
> >> >> >> > > >> > > QNX
> >> >> >> > > >> > > is
> >> >> >> sending
> >> >> >> > > >> that
> >> >> >> > > >> > > same struct, so there always should be the same
> >> >> >> > > >> > > something
> >> >> >> > > >> > > read
> >> >> >> when a
> >> >> >> > > >> > > reply
> >> >> >> > > >> > > and request is made... do you see what I mean ?
> >> >> >> > > >> > >
> >> >> >> > > >> > >
> >> >> >> > > >> > > "Alexander Nickolov" wrote:
> >> >> >> > > >> > >
> >> >> >> > > >> > >> I guess you have a blocking socket. It simply means
> >> >> >> > > >> > >> there's no data sent from the other side. You'll need
> >> >> >> > > >> > >> a separate thread for timeout and close the socket
> >> >> >> > > >> > >> when the timeout kicks in. Then your recv() will fail
> >> >> >> > > >> > >> on
> >> >> >> > > >> > >> the first thread.
> >> >> >> > > >> > >>
> >> >> >> > > >> > >> --
> >> >> >> > > >> > >> =====================================
> >> >> >> > > >> > >> Alexander Nickolov
> >> >> >> > > >> > >> Microsoft MVP [VC], MCSD
> >> >> >> > > >> > >> email: agnickolov@mvps.org
> >> >> >> > > >> > >> MVP VC FAQ: http://www.mvps.org/vcfaq
> >> >> >> > > >> > >> =====================================
> >> >> >> > > >> > >> "saxxyb" <saxxyb@discussions.microsoft.com> wrote in
> >> >> >> > > >> > >> message
> >> >> >> > > >> > >> news:441E9406-66EE-4E53-9CA6-AB8EE4F7ADB2@microsoft.com...
> >> >> >> > > >> > >> > Hi
> >> >> >> > > >> > >> >
> >> >> >> > > >> > >> > -------------------------------------------------------------
> >> >> >> > > >> > >> > Function Def:
> >> >> >> > > >> > >> >
> >> >> >> > > >> > >> > readn(SOCKET sfd, char FAR* buffer, long nbytes )
> >> >> >> > > >> > >> > {
> >> >> >> > > >> > >> > long nleft;
> >> >> >> > > >> > >> > int nread;
> >> >> >> > > >> > >> >
> >> >> >> > > >> > >> > nleft = nread;
> >> >> >> > > >> > >> >
> >> >> >> > > >> > >> > while(nleft >0)
> >> >> >> > > >> > >> > {
> >> >> >> > > >> > >> > nread = rev(sfd, (char FAR *) buffer, 1000,
> >> >> >> NO_FLAGS_SET);
> >> >> >> > > >> > >> > if(nread < 0)
> >> >> >> > > >> > >> > return nread;
> >> >> >> > > >> > >> > else if(nread == 0)
> >> >> >> > > >> > >> > break;
> >> >> >> > > >> > >> > nleft -= (long) nread;
> >> >> >> > > >> > >> > (char *)buffer += nread;
> >> >> >> > > >> > >> > }
> >> >> >> > > >> > >> >
> >> >> >> > > >> > >> > return ((int)(nbytes - nleft));
> >> >> >> > > >> > >> > }
> >> >> >> > > >> > >> > -----------------------------------------------------------
> >> >> >> > > >> > >> > The above function is called every second with a
> >> >> >> > > >> > >> > specific
> >> >> >> struct
> >> >> >> > > >> which
> >> >> >> > > >> > >> > does
> >> >> >> > > >> > >> > fine, but then we added a second struct that we also
> >> >> >> > > >> > >> > call
> >> >> >> > > >> > >> > this
> >> >> >> > > >> function
> >> >> >> > > >> > >> > with
> >> >> >> > > >> > >> > / So, every second we call readn with one struct,
> >> >> >> > > >> > >> > and
> >> >> >> > > >> > >> > then
> >> >> >> > > >> > >> > another
> >> >> >> > > >> > >> > struct.
> >> >> >> > > >> > >> > After 2.5 hours of this running, as we make call for
> >> >> >> > > >> > >> > the
> >> >> >> > > >> > >> > secod
> >> >> >> > > >> > >> > struct
> >> >> >> > > >> > >> > the
> >> >> >> > > >> > >> > "
> >> >> >> > > >> > >> > recv" function causes the program to not respond...
> >> >> >> > > >> > >> >
> >> >> >> > > >> > >> > Any clues ?
> >> >> >> > > >> > >> >
> >> >> >> > > >> > >>
> >> >> >> > > >> > >>
> >> >> >> > > >> > >>
> >> >> >> > > >> >
> >> >> >> > > >> >
> >> >> >> > > >>
> >> >> >> > > >>
> >> >> >> > > >>
> >> >> >> > >
> >> >> >> > >
> >> >> >> > >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>
- Next message: Randolph Neall: "Cable modem/router causes error 10054, "Connection was forcibly reset by remote host""
- Previous message: saxxyb: "Re: recv function"
- In reply to: Alun Jones [MSFT]: "Re: recv function"
- Next in thread: Arkady Frenkel: "Re: recv function"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
