Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site ucbvax.ARPA Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!dillon From: dillon@ucbvax.ARPA (The Sherif "Matt D.") Newsgroups: net.unix-wizards Subject: Re: Help: 4.2bsd IPC routines/TCP sequence error? Message-ID: <5669@ucbvax.ARPA> Date: Thu, 21-Mar-85 03:01:05 EST Article-I.D.: ucbvax.5669 Posted: Thu Mar 21 03:01:05 1985 Date-Received: Fri, 22-Mar-85 01:08:07 EST References: <601@marlin.UUCP> Distribution: net Organization: University of California at Berkeley Lines: 35 > 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