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
