Incorrect order of packets are frequently caused by improper use of the message pump. The rule is simple: never call any form of message pump from an event handler. This is true for ICS but also any other component even simplest one such as TButton ! Pay attention that the message pump may is called by many GUI functions such as message box or modal forms. It may also be called by any component (poorly designed UI component) or even called on purpose (for example sync methods of ICS).
Setting multithreaded property to true affect the way the component handle messages. See source component code to understand what it does exactly and why it could affect your code. If you set multithreaded property to true for the server component, it is likely that you must also set it for any child component created for client connection. The purpose of the multithreaded property is to tell the component it is working outside of the main thread context. Also pay attention to all exception which are silently shutdown (except clause empty). Shutdown exception may hide some problem. -- 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 7:39 PM Subject: Re: [twsocket] Very strange problem with server andclient software... > Thanks for the info guys... :) > > I assumed the issue must somehow be related to sequencing issues impacted > by > the faster, local speeds, although exactly how I wasn't sure. > > On further testing, I have discovered something of interest. After > setting > the TWSocketServer MultiThreaded property to true, it appears to possibly > fix the instability problem, but seems to inject another problem. With > MultiThreaded set to true, I generated some additional log info from the > Server app. Oddly, I found that the packet handling sequence order is > altered in a particular handshaking process, causing the channel security > syncing to fail. > > Here is some pseudo logic for what happens when MultiThreaded is set to > True. Again, for some reason, this DOESN'T happen on my development > machine, just on some other machines, and only when Server and Client are > on > the same machine: > > - Discrete portion of session logic flow during channel sync: > 1. [SERVER] Send Packet to Client with random Challenge parameters. > 2. [SERVER] Resync Server side of Client channel using new security > parameters. > 3. [CLIENT] Upon receipt of Challenge parameters from Server, resync > Client > side of channel using new parameters. > 4. [CLIENT] Send Challenge response to Server using new channel > parameters. > 5. [SERVER] Receive and validate Client Challenge response, asserting > trusted or untrusted channel state on pass / fail. > > The problem is that #2 MUST occur before #5. However, with MultiThreaded > set to true, it does not occur in the correct order on some machines when > both programs are running on the same machine. I don't quite understand > why > that would be, as #1 and #2 are basically consecutive lines of code, where > #5 is a process that will be handled by a different thread function after > receiving the client response packet. It exhibits symptoms like > ProcessMessages is being called after #1, which receives and process the > Client response before #2 can occur, although I am not calling > ProcessMessages. > > Pseudo logic for the code fragment for #1 and #2 would be: > - Thread function 1 > Line 1. Generate Random challenge parameters. > Line 2. Send Client Packet with info. > Line 3. Resync Client Channel parameters. > ... > - Thread Function 2 (upon receipt of Client Challenge Response) > If ValidateClientParms then > Session = trusted > else > AbortSession. > > Question: Why would setting MultiThreaded to True cause Thread Function 2 > to fire after Thread Function Line 2 which handles the response, before > Thread Function Line 3 can execute? Why would this only occur with > MultiThreaded set to true and only on some machines and not others? > > I can work around this by preparing the Server Challenge packet first, > re-initializing the channel, then bypassing the channel overhead and > sending > the prepared packet raw. However, that would be a real kludge and I am > more > concerned that similar sequencing issues might surface in other areas. > > Thanks much for your time... > > Hoby > > Previous Francois response: > > I don't think it is a winsock bug. > The main difference between running programs on different machine and on > the > > same machine is the speed. On the local machine, it is likely to be very > fast. You have to pay attention to your DataAvailable event handler so > that > it doesn't care how data is split into packets. > > I suggest you use SocketSPY (see usermade page at ICS website) to spy on > the > > communication between your programs, either when running on different > computers or running on the same computer. You may modify SocketSpy > slightly > > to log all traffic to a file foe later analysis and comparing running the > program locally or remotely. > > > -- > 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
