Faster way to get TCP/IP Messages

[ConvertFromOldNGs]

by JADE Kid - Ray Hidayat >> Mon, 8 Jan 2001 13:15:16 GMT

Currently, I have found a way to connect to another server with TCP/IP, but I am having one problem. Sometimes the server can send a lot of messages, and I miss them. I use Asynchronous transfer.

Is there a way I can not miss a single message?

If it helps, my receiving method for Asynchronous transfer has the 'readBinaryAsynch' method in the epilog, so while the method is executing I can miss things.

--
Ray Hidayat
JADE Kid - 2000
www.jadekids.com

[ConvertFromOldNGs]

by Wilfred Verkley >> Mon, 8 Jan 2001 21:20:59 GMT

The TCP protocol should ensure that everything the sender sends to you gets to you, and in the order which the sender sent it (as opposed to UDP which is faster but doesnt have those properties).

Also be aware that the TCP, the messages may not arrive in the same size chunks in which they were sent. If you know the size of the messages you are about to receive, simply set fillReadBuffer on the TCPIPConnection object to be true and you want get a callback only until the length of that message has been received. If you dont know the length of your message until you parse it, plonk all the data received into your own buffer until you see your End-Of-Message marker (being careful you dont chop of thebegin ning of any next message).

Do a write in the receiver you have set for your readBinaryASynch. Thats probably the easiest way to debug it.

[ConvertFromOldNGs]

by Krull >> Mon, 8 Jan 2001 22:22:26 GMT

If you dont know the length of your message until you parse it, plonk all the data received into your own buffer until you see your End-Of-Message marker (being careful you dont chop of the beginning of any next message).

Another way to handle variable length messages is to prefix all messages with a short header containing the length and then perform two reads with fillReadBuffer set - an asynch read for header size, the second read for message size (obtained from header). You can simplify the logic by reading the data part of the message synchronously in the same asynch read callback which processed the header; this is not a bad approach, if the reader process can't continue until it has recieved the entire message (it may as well block on a synchronous read request).