HP3000-L Archives

May 2003, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Evan Vaala <[log in to unmask]>
Reply To:
Evan Vaala <[log in to unmask]>
Date:
Fri, 23 May 2003 16:57:48 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (63 lines)
On Fri, 23 May 2003 11:52:41 -0700, Gavin Scott <[log in to unmask]> wrote:

>Bill writes:
>> We had a sockets application that was occasionally having problems
>> getting the entire message buffer over the network to the remote host.
>> Our message lengths were about 1500 characters.  We decided to try
>> using a loop to send one byte at a time with the sockets "send" and
>> "recv" calls.  Problem disappeared and has not returned.
>
>I absolutely do not intend the following to sound insulting, but the above
>indicates a complete lack of understanding of how stream-oriented network
>protocols like TCP work.  Please get (and read) a book on network
>programming such as:
>
>   http://www.amazon.com/exec/obidos/tg/detail/-/013490012X
>
>The short answer is that you should "send" as many bytes as you've got (up
>to the transport's maximum which is typically around 30KB) and you should
>"recv" in a loop asking for as many bytes as you need until you receive a
>complete message.
>

Just wanted to mention another scenario.

There are situations, such as binary transfers, where you may have to
create your own packeting mechanism within the data stream.  This can be as
basic as  the the first n number of bytes that the receiver gets is the
length of the expected packet.  The receiver then knows how many bytes to
expect and can buffer/loop recv calls accordingly.

A brief description...

Your program must first "recv" a buffer/stream of data.

The first n bytes represent the packet length.

Set a decrementer variable to the expected length.

If the first buffer read is less than the expected number of bytes, reduce
the decrementer by the buffer size.
Issue another recv call.

Loop the recv/buffer process until the decrementer is zero.

If your packet has ended in the middle of the last recv buffer, the next n
bytes in the buffer is the length of the next packet.

And the process repeats itself.

Remember that the sender has to adhere to the same packeting mechanism that
the receiver is expecting.

Also, in this scenario, typically, the sender must know the size of the
data, or at least the packet, being sent ahead of time.

Just my 0.02

Evan Vaala
Rockwell Automation

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2