I use this functions as normal, can you send me a reduced example that fails.
Then i can help to you, I need to do some changes at kernel to eliminate some restrictions. about INET Best regards, Miguel Angel Marchuet bhays escribió: > Has anyone fully tested InetRecvAll() ? > > We have an unresolved problem with the Internet communication functions. > We've been unable to reduce it to a small sample, so I don't expect this to > stop finalizing a release. But it would be good to know if a lot of people > have > done a lot of testing of the changes from a few months back regarding > buffers. > > We have two programs, a server and a client, that talk to each other > ultimately using > nLength := InetRecv( ::Socket, @s_cRequest ) > nBytesRead := InetRecvAll( ::Socket, @s_cResponse, nLength ) > and > METHOD Send( cSend, nLen ) INLINE InetSend( ::Socket, cSend, nLen ) > METHOD SendAll( cSend, nLen ) INLINE InetSendAll( ::Socket, cSend, nLen ) > > Initial custom "handshaking" using InetRecv() works fine to establish the > length of the real > buffer to transfer down from the server (current test is just 270 bytes). > But when the server sends it, the client fails on the first call to > InetRecvAll() > which just reports zero bytes read. > > This code was working great for years, the last build was with last > September's xHarbour. > We didn't need to touch until this past April when we found the problem, and > we've > gone in circles a couple of times trying to chase it. > > The real problem is that it is intermittent. Using the exact same > executables, if I start the server and test the client it may work. > If it does, it usually will work for even a dozen tests. Eventually it > fails. > If I restart the server, the client may fail the first time. When it does, > it usually fails consistently. > So behavior seems to be dependent upon random startup issues, who knows > what... > Perhaps it works if the server is started during on an even-numbered > second but not if the time is on and odd-numbered second. It's very weird, > and hard to debug. > > Does anyone have any ideas? > > TIA, > > -- > Brian Hays > > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Patrick Mast, xHarbour.com > Sent: Saturday, August 02, 2008 3:52 AM > To: xHarbour-Developers > Subject: [xHarbour-developers] New release > > Hey Guys, > > I'd like to call for a release freeze if there are no pending bug fixes. > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > xHarbour-developers mailing list > xHarbour-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xharbour-developers > > __________ Información de NOD32, revisión 3303 (20080728) __________ > > Este mensaje ha sido analizado con NOD32 antivirus system > http://www.nod32.com > > > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ xHarbour-developers mailing list xHarbour-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xharbour-developers
