Article View: borland.public.cppbuilder.internet.socket
Article #3192Re: packet contatenation
From: Remy Lebeau (TeamB)
Date: Tue, 25 Oct 2005 21:06
Date: Tue, 25 Oct 2005 21:06
54 lines
3097 bytes
3097 bytes
"Joe Black" <nospam@newsgroup.com> wrote in message news:435e5931$1@newsgroups.borland.com... > For some reason though several packets seem to get > concatenated together to form one larger packet That is perfectly normal socket behavior. A socket buffers all outgoing data until either the buffer is full or until the socket has no pending data waiting to be sent. > if I slow down the transmit thread to say every 200ms this > problems dissapears Yes, because you are allowing the socket to have some time to clear its internal buffer before more data is passed to it. > Is there anyway to determine whether the last packet was > sent before I attempt to send the next one No. But that is not needed in the first place. TCP is a stream transport. It doesn't care what the contents of the data is. It sends a stream of arbitrary bytes. So you are responsible for formatting your outgoing data in such a way that the receiver knows where one packet ends and the next begins. There are three ways to do that: 1) send messages that are all the same byte size. The receiver reads the necessary number of bytes and then processes them. 2) preceed each message with a fixed-sized length value. The receiver first reads the necessary number of bytes to receive the length and then continues reading the specified number of bytes to finish the message. 3) Place a unique terminator sequence of bytes at the end of a message. The terminator cannot appear in the message contents at all. This way, the receiver continues reading bytes until the terminator is encountered. In all three situations, you have to code your reading to handle three different scenerios when a read event occurs: 1) no bytes are available at all 2) fewer bytes are received than are needed for a complete message, requiring you to wait for another read event in order to receive more bytes for that message. 3) bytes from multiple messages are received at one time. In all read events, you should buffer the received bytes and then process and remove any complete messages that are in buffer, leaving any incomplete messages in the buffer for later processing. Gambit
Technical Details
Message-ID:
<435e9db5$1@newsgroups.borland.com>Path:
arc1-ca.pugleaf.net!g2news1.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsgroups.borland.com!not-for-mailReferences:
<435e5931$1@newsgroups.borland.com>Show Full Headers
Complete Article Headers
X-Google-Thread: 11508e,de4e39df019561af X-Google-Attributes: gid11508e,public X-Google-Language: ENGLISH,ASCII-7-bit From: "Remy Lebeau \(TeamB\)" <no.spam@no.spam.com> Newsgroups: borland.public.cppbuilder.internet.socket References: <435e5931$1@newsgroups.borland.com> Subject: Re: packet contatenation Date: Tue, 25 Oct 2005 14:06:27 -0700 Lines: 56 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 NNTP-Posting-Host: 68.69.17.41 Message-ID: <435e9db5$1@newsgroups.borland.com> X-Trace: newsgroups.borland.com 1130274229 68.69.17.41 (25 Oct 2005 14:03:49 -0700) Path: arc1-ca.pugleaf.net!g2news1.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsgroups.borland.com!not-for-mail