Line mode is one way to handle data. It applies only when data is terminated by a given delimiter. The other way is sending a data length somewhere. I understand that the application you write must use that way of doing things.
It is not that difficult to implement but the component can't do it for you since there are so many ways to send data length. The ide to implement it is to use a receive buffer where you append received data as it comes in (in OnDataAvailable event handler). Each time you received something, you check if you have enough data to have the length into it. If you haven't the length, then you do nothing until the next packet comes in. Once you have enough data to have the length, you compare the length field with the actual received length. If you have received all (and maybemore)data,then you can process it and remove it from the start of buffer (without throwing away any data already received but part of the next message). -- [EMAIL PROTECTED] http://www.overbyte.be ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <twsocket@elists.org> Sent: Sunday, December 18, 2005 3:29 AM Subject: [twsocket] assembling data on socket receive > Francois Piette, > thanks for responding to my last post about tcp primer. I looked into > linemode and it looks very useful. The problem for me is I am writing a > chat > client with ICS and I'm writing both an unofficial third party irc and > yahoo > chat client but i'm struggling with handling the receive data because > there > is not a set boundary for the ending of a packet on yahoo, for example. > Each > yahoo packet that comes in is required to have a YMSG header which is > exactly 4 bytes long followed by an additional 16 bytes which makes up a > full 20 byte packet header. The 11th and 12th bytes are the actual packet > length. > > standard packet layout > > YMSG<4 random bytes>2 byte packet length<1 random byte>1 byte service > type<8 > random bytes> = 20 byte header > > If the packet's payload is greater than 255 bytes then the 9th byte > is incremented by 1 and the remainder is stored in the 10th byte. > > So a 9th byte of chr($01) and a 10th byte of chr($E1) would give me a > payload length of 481 bytes and by adding 20 you would get the entire > packets length which would then be 501 bytes. > > I can always calculate the packet length like this > ord(byte9)*256+ord(byte10)+20 > > This means that the packets payload is calculated in the 9th and 10th > bytes > and I'm then adding the 20 byte header to get the whole packets length in > bytes. > > YMSG is an undocumented protocol and has no official RFC tp make matters > harder. With that said I'm wondering how I could ensure that i can analyze > these packets using this calculation. If I split the data at the 12th byte > which is the service type and subtract 11 from the 12th byte position i'm > able to extract the packet length and perform calculations but I cannot > always guarantee that without using linemode that a -11 position from the > 12th byte will exist or even have enough bytes in the receive buffer to > copy > to according to the packet length. If i'm not making sense to you I can > give > you a proper example in delphi code if you wish with comments. I'm stuck > on > the fact that linemode would be perfect for me but unfortunately i don't > see > a common pattern to go on in order to use linemode since the end of the > packet isn't a given set of delimiters. It could be an extended character, > a > null byte, a set of null bytes etc.. so the only way is finding the 4 byte > YMSG packet header and incrementing the position to get the 9th and the 10 > bytes for the actual length. Is there any way i can do this properly that > you could recommend? I originally wondered about this and figured i could > check the packet's length against the current length of the received > buffer > and if the received buffer was smaller i could repeat an operation until > the > received buffer was filled again or something of that nature but i'm not > sure it that would work out the way i imagined it. > > If you can offer me advice i could sure use it because i love ics and I > would like to get a working example sometime soon, one which is able of > processing virtually every packet properly without examining data from a > premature OnDataAvailable event trigger. > > -brad > -- > 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
