Help: 4.2bsd IPC routines/TCP sequence error?

The Sherif "Matt D." dillon at ucbvax.ARPA
Thu Mar 21 18:01:05 AEST 1985


> OVERVIEW:
> I am working on a series of programs that communicate via TCP over
> a 10mb ethernet. The hosts are all Vaxen (750s and 780s) all running
> 4.2bsd. The application is written in C and uses the calls outlined
> in the 4.2bsd Interprocess Communications Primer. Our problem is that
> when we send records from one host to another, the order in which they
> are received is not the same as the order they were sent. The problem
> seems to be in the timing between repeated calls to send().

Your problem is NOT with the socket.  STREAM sockets are GUARENTEED not
to duplicate or mess the order of any data.  Therefore, you do NOT have
to number your packets.  

The problem is in the recieving end of the program.  If the transmission side
of the program can get across more than one send before the recieving end
of the program does it's recv, the recieving end recv will get BOTH sends all
in one buffer... or all of one send and part of another.  STREAM sockets do
not preserve BLOCK BOUNDRIES as UDP sockets do.  

The only reason the code seemed to work when you had the printf's was because
those printf's caused a delay large enough enabling the recieving side to
read in the data before the sending side could send another packet.

So, to recap, the reciver side is at fault because you assume block boundries
stay intact when in fact they don't.  One recv may read several sends worth
of info.   Also, you do not need to number your packets if you are using
a STREAM socket.

I hope I've helped out,
				
				Matthew Dillon



More information about the Comp.unix.wizards mailing list