Pipes, sockets and coms processes

[Mike Anderson]

With stream sockets, there is no way for the receiver to know how long the
message is without the programmer's intervention.  I.e., what you
typically do is to set up a fixed size header format that includes a
length field.  You read from the socket until you have a full message and
then you use the length field to tell you how many more bytes you have to
read before you have the complete message.

A word of caution:  the select() call will indicate that there is data to
be read when the very first byte shows up.  Stream sockets do not preserve
record boundaries so you have to use an approach like the one outlined
above and loop on the read until enough data arrives to determine the
actual message length.

Here is an example:

[[Ed's Note: Pretty long - I dumped it in the archives. -bdg]]

FTP:	Hostname : titan.rice.edu (128.42.1.30)
	Directory: sun-source
	Filename : servesend.c
	Filesize : 9942 bytes

Archive Server Address: archive-server at rice.edu
Archive Server Command: send sun-source servesend.c

The compilation is a simple cc (i.e., ignore the VXWORKS stuff 'cause
that's for a real-time single board computer that we sell) and it would
look like this:

cc -o benchmark benchmark.c
cc -o recv recv.c

Start the benchmark program with:

benchmark 3000 1000 1     (port 3000, 1000 1024-byte msgs, 1 client)
and 
recv "<benchmark host name>" 3000  (same port as benchmark)

They should connect and go to town :-).  The number of messages specified
is DIVIDED evenly among the number of clients (e.g.,  if there were 2
clients they would each get 500 msgs).  Just run recv as many times as you
have clients specified.

Good luck,

Mike Anderson
mea at sparta.com