Hi, this is David.

I asked about a method to recognize the "splitted packets" and to join 
them upon arrival of the last one. So far my protocol works fine, and 
all the data is assembled in an orderly manner. For large texts or 
binary data, the clients knows how to handle it as follows:
The "Redirecting Text MEssage" just means, the text buffer is going to 
be further processed in a function called "HandleResponse()".

sender side-----------------------------------------
Line    7: out> txt 1561
Line    8: (Written 17 bytes)
Line    9: (received 16 bytes): sendtxt
Line   10: out> sendtxt
Line   11: out> msg AliasName and DriverName a...(too long to display)

recipient side---------------------------------------------
Line   10: (received 18 bytes): txt 1561
Line   11: out> txt 1561
Line   12: out> sendtxt
Line   13: (Written 15 bytes)
Line   14: Preparing Temp Buffer...
Line   15: Received 1460 bytes, Remaining 3123 bytes
Line   16: Received 1460 bytes, Remaining 1663 bytes
Line   17: Received 203 bytes, Remaining 203 bytes
Line   18: All packets finished.
Line   19: Redirecting Text Message...
Line   20: out> msg AliasName and DriverName a...(too long to display)
Line   21: (!!) Command: msg AliasName and DriverName are m...(too long 
to display)
------------

The "sendtxt" is a command through which the recipient tells the sender 
"hey I'm ready to get the long buffer".
This mechanism works very fine if I enter the command one by one. But 
today I wanted to know if the recipient can handle successive "long msg" 
requests by one single sender. So I tried a "stress test" to send the 
1561 widechar long text on an interval of 10ms, to the recipient. There 
are totally 200 requests to be sent consecutively.

Sometimes it works fine, but sometimes .. the following happens

Sender side-----------------------------------------
Line 1720: out> txt 1561
Line 1721: (Written 17 bytes)
Line 1722: Warning! Session is busy!
Line 1723: (received 25 bytes): sendtxt<JUNK>
Line 1724: out> sendtxt<JUNK>
Line 1725: Warning! Session is busy!
Line 1726: Warning! Session is busy!
Line 1727: Warning! Session is busy!
  :
  :

<JUNK> = some strange characters

Recipent side---------------------------------------
Line 4112: (received 18 bytes): txt 1561
Line 4113: out> txt 1561
Line 4114: out> sendtxt
Line 4115: (Written 15 bytes)
Line 4116: Preparing Temp Buffer...
Line 4117: Received -1 bytes, Remaining 3123 bytes
Line 4118: WARNING! Transfer went wrong! Error 0
Line 4119: out> fail
Line 4120: (Written 9 bytes)

Although the recipient sent 15 bytes of command "sendtxt" (line 4114), 
the sender receives 25 bytes, with 10 bytes of junk following it. 
Supposingly, the recipient should say "fail" to the sender and the 
sender shoud receive it. But in this case, since the "sender" is kept 
asking for more send (triggered by Timer, where interval=10ms), so there 
are many "Warning! Session is busy!" messages appearing (because the 
previous send-long-text action is still pending). Although the "fail" 
message was sent from the other party, it seems that the "Sender" never 
received this message.

Also, out of so many times of test I've  done, the "junk" fter the 
"sendtxt" is ALWAYS THE SAME junk. So.. I think there might be some 
problem in my code... perhaps is it something to do with multithreading?

This problem only occur when I repeatly do the test. As in above you can 
see the line number gets very big because I haven't got a problem from 
line0... till now.. but I got to test the protocol under stress.. 
because it's going to be some sort of "database server."

Please would anybody give me a clue what's going wrong here?

Thanks!

David













-- 
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

Reply via email to