> 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
This is really the most common task when dealing with TCP transmission. You have such "packet reassembly" in almost all ICS components. TWSocket itself has a LineMode that does this reassembly for lines. Lines are not necessary text line. It is just a convenient name to specify any variable length data with end of data marker. > Please would anybody give me a clue what's going wrong here? How would you receive help when we don't know anything about your code ! It is likely that the problem is at the receiving part. -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be ----- Original Message ----- From: "Kei" <[EMAIL PROTECTED]> To: "ICS support mailing" <twsocket@elists.org> Sent: Tuesday, November 01, 2005 9:45 AM Subject: [twsocket] transmission stress test > 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 -- 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
