[comp.sys.sun] Pipes, sockets and coms processes

rbs@aiai.ed.ac.uk (Robert Scott) (01/11/91)

I'm trying to write a program to get a number of processes distributed
over a number of Sun SPARC stations to exchange information using sockets
over the ethernet.

My question is:

Given two processes communicating via a socket, how does the receiver know
the length of the senders message?  In the relevant manual on
interprocessor communication the examples given send fixed length
messages. I need to be able to send variable length messages where the
receiver won't know message length at compile time.

Any help with this, or any general advice on how to write such monsters
would be greatly appreciated.

Rob Scott
Department of AI		rbs@uk.ac.ed.aiai
University of Edinburgh
SCOTLAND

rstevens@noao.edu (Rich Stevens) (01/12/91)

In article <1180@brchh104.bnr.ca> rbs@aiai.ed.ac.uk (Robert Scott) writes:
>My question is:
>
>Given two processes communicating via a socket, how does the receiver know
>the length of the senders message?

The answer is: it depends on the underlying protocol being used with the
socket.  If you're using a stream protocol such as TCP, there are no
record boundaries at all provided by the system.  The applications at both
ends have to build them and use them.  Common examples are newlines to
mark lines with ascii text or one or more count bytes in front of every
record.  If you're using a datagram protocol such as UDP, each datagram
can be considered a "record".  But, beware of lots of other subtleties if
you use a datagram approach (loss of datagrams, buffer space, etc.).
Sounds like what you're looking for is something like Xerox's SPP--a
reliable protocol with record boundaries.  But, Suns don't come with it.

	Rich Stevens

fkittred@spca.bbn.com (Fletcher Kittredge) (01/12/91)

In article <1180@brchh104.bnr.ca> rbs@aiai.ed.ac.uk (Robert Scott) writes:
>Given two processes communicating via a socket, how does the receiver know
>the length of the senders message?  In the relevant manual on
>interprocessor communication the examples given send fixed length
>messages. I need to be able to send variable length messages where the
>receiver won't know message length at compile time.

What is your protocol?  TCP/IP is a byte stream protocol, so if you are
using it, then you will have define your own protocol to send your own
packet headers with lengths for the data portion of the messages.  This is
less difficult than it sounds.  I recommend that you pick up a copy of
Stevens, "Unix Network Programming" [Prentice-Hall]

Regards,
Fletcher Kittredge
617-873-3465  /  fkittred@bbn.com  /  fkittred@das.harvard.edu

mea@sparta.com (Mike Anderson) (01/17/91)

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@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@sparta.com