Re: [twsocket] Very strange problem with server and client software [solution]...
Hello Hoby, If PutDataInSendBuffer and Send 0 at the end makes a difference then you probably have a problem in the receiver. Same reason as the reason it depent from machine to machine. You can try also with SocketSpy, if it also make a difference then you sure have to check over there. - You mention mulitthreaded = 'True. This means that the TWSocket is Created in Execute method of a thread, or Ataccehd to a tread. Did you do one of both ? - Are you sure never message pump is called from in OnDataAvailable method, or any other method of TWSocket ? --- Rgds, Wilfried [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html http://www.mestdagh.biz Friday, July 28, 2006, 23:32, Hoby Smith wrote: 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
Re: [twsocket] Very strange problem with server and client software[solution]...
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
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
