realbasic-nug
[Top] [All Lists]

Re: TCP packet - are separate packets collected into one?

To: REALbasic NUG <realbasic-nug@lists.realsoftware.com>
Subject: Re: TCP packet - are separate packets collected into one?
From: Thomas Tempelmann <tempelmann@gmail.com>
Date: Thu, 26 Feb 2009 23:02:36 +0100
Authentication-results: mx.google.com; spf=neutral (google.com: 74.124.194.228 is neither permitted nor denied by best guess record for domain of realbasic-nug-bounces@lists.realsoftware.com) smtp.mail=realbasic-nug-bounces@lists.realsoftware.com; dkim=neutral (body hash did not verify) header.i=@gmail.com
Delivered-to: listarchive@realsoftware.com
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=cBwo0uO7nvzDfTRk48LMQmGoXxql5nWFH7KBnGfwnx8=; b=AtAquawuUO9zEvYSzywNYpoIgSOdeugIeyYNL9WaqdTU5p+ny9jhqU7KMmitS2m3xR HZAZJk3m9epN9yQXU/SwuJa0qeGoOtdefEMyApdwM8iqbsUp3//OJ+QXseuTeM9bBD38 AWKC5PyslLBxpmE7dqtqcmLtHW33hOMuEYPuI=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=Au7C7p68GgfAlE7qcV/dUputMiAWbEse5U4fxl9WYlqaSIwfA5EAK2xpOCR8l1lx/7 uwRPe1baqz72JX3rPhzY6F+M7znfhOFpzsaP4kwFyY8OXIvogBKceruZs+INw12lZ9SQ KJa4U++/fn2oVSobw3tCYGeMrkWIFJAK2tu6U=
In-reply-to: <49A71007.4030406@bellsouth.net>
References: <89fe53800902261201u4d7703d7s5a7f9edeab9bad45@mail.gmail.com> <49A70E35.1090504@bellsouth.net> <49A71007.4030406@bellsouth.net>
Reply-to: REALbasic NUG <realbasic-nug@lists.realsoftware.com>
Sender: realbasic-nug-bounces@lists.realsoftware.com
> me.write "TEST MESSAGE!"
> me.write "SECOND MESSAGE!"
>
> In a single firing on the dataavailable event on the receiving socket, you
> might get:
>
> TEST MESSAGE!SECOND MESSAGE!
>
> or you might get
>
> TEST MESS on the first firing of dataavailable
>
> and AGE!SECOND MESS on the second firing

Right. That's why I've implement the following format:

I always send a header of 8 bytes first, 4 bytes being a code for the
type of data to follow, and 4 bytes being the amoung of data to follow
for that type. then comes the actual data ("payload").

For reading, I use a state variable telling me how much of the payload
I am expecting. At first it's zero. That means that I'm waiting for
the header.
Thus, while waiting for the header, I check if at least 8 bytes are
available. If not, I return. Otherwise I read those 8 bytes, set the
memblock's LittleEndian to FALSE (also when creating the header!) and
read the type code and payload length. I store the payload len.
Next, I check if the expected payload len is non-zero. Then I check if
the socket has that much data available yet. If not, I return. If the
data is there, I read only that amount from the socket that the
payload length designates.
After processing this block, I loop back to checking for another header.

That's a pretty safe and extensible algo, I think.

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>


<Prev in Thread] Current Thread [Next in Thread>