🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: borland.public.cppbuilder.internet.socket
Article #3192

Re: packet contatenation

#3192
From: Remy Lebeau (TeamB)
Date: Tue, 25 Oct 2005 21:06
54 lines
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-mail
References: <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