As I understand, you where - before you fix - sending some data which will result is some response being received, but at the time you send data your code is not yet ready to process the response. When runnin on different computers, there was enough time between the time you send the data and the time you receive the response to setup your program to process the response. But when running on the same computer, you get the response very quickly and your program is not able to prepare to receive the response. This is probably caused by the task switch. When your program sent the data, and a task switch occur, the sender loose the CPU, the receiver receive it and has enough time to build and send his response during a single time slice he received. The the sending program has CPU back but has not yet prepared itself to receive data and you have a problem.
> None-the-less, I am concerned that the surfacing of this issue > might reflect some deeper logic flaw in the system as a whole. If what I understood is correct, I think you have a flow in the design. You must ALWAYS be prepared to process a response before sending a request, even when your client and server programs run on different computers. Then sending program may always loose CPU just after having send his request and may receive it back only when the response has already been received by winsock. See from the sending program, the response is received instantly after the request has been sent. That is why the program has to be able to process the reply without any delay. -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be ----- Original Message ----- From: "Hoby Smith" <[EMAIL PROTECTED]> To: <twsocket@elists.org> Sent: Friday, July 28, 2006 11:32 PM Subject: Re: [twsocket] Very strange problem with server and client software[solution]... > Hello. Well, ultimately, here is my solution. > > This appears to work 99.9% of the time, maybe 100%. There was one > failure, > but not sure if it was a related problem... ;) > > Oddly, turning on the TWSocket MultiThreaded property tends to alleviate > the > majority of symptoms. As I understand, the only major difference when > MultiThreaded is on is that the ClientSocket utilizes its own messaging > interface? Right? > > As for the issue I mentioned in the last email I posted, I solved the > sequencing issue this way. Previously, I had a global "send packet" > routine, wrapped in a Critical Section for thread safety. I use a single > Global send routine so that I can gather statistics in one place (total > bytes sent, total packets sent, total session bytes, etc). Since the > MultiThreaded message loop was picking up responses before I was prepared > to > receive them, I created an additional couple of global routines. One is a > global "post packet" routine, which processes the packet, but uses > PutDataInSendBuffer to prepare and que up the outbound traffic (framing, > encryption, etc), instead of sending it immediately. Then, when I am > prepared to handle any related responses, I call a new global "Send > Buffer" > procedure, that simply issues a 0 byte Send on the ClientSocket to begin > sending the que'd data. I then changed the sequence order sensitive > handshaking routines to use the PostPacket / SendBuffer routines instead. > > This approach has appeared to fix the issue sufficiently. I am perplexed > as > to the nature of the issue itself, but for now, this will suffice. The > scenario of both programs (client and server) being on one system is never > going to occur during a "live production" environment. Solving this issue > is really only relevant for development, testing and demonstration > purposes. > > None-the-less, I am concerned that the surfacing of this issue might > reflect > some deeper logic flaw in the system as a whole. > > Does this solution sound appropriate? It appears to work fine. And does > the problem issue sound like it should occur at all? Or does it sound > like > I have done something really BAD? I still can't get over the fact that it > works fine and never occurs on the proverbial "my machine"... :) > > Thanks... > > Hoby > > > -- > To unsubscribe or change your settings for TWSocket mailing list > please goto http://www.elists.org/mailman/listinfo/twsocket > Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be