From owner-freebsd-hackers Fri Nov 15 11:15:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA09572 for hackers-outgoing; Fri, 15 Nov 1996 11:15:35 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA09565 for ; Fri, 15 Nov 1996 11:15:31 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA26626; Fri, 15 Nov 1996 11:58:52 -0700 From: Terry Lambert Message-Id: <199611151858.LAA26626@phaeton.artisoft.com> Subject: Re: Sockets question... To: fenner@parc.xerox.com (Bill Fenner) Date: Fri, 15 Nov 1996 11:58:51 -0700 (MST) Cc: terry@lambert.org, fenner@parc.xerox.com, scrappy@ki.net, jdp@polstra.com, hackers@freebsd.org In-Reply-To: <96Nov15.101231pst.177557@crevenia.parc.xerox.com> from "Bill Fenner" at Nov 15, 96 10:12:18 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> What you need to do is write all your data to the network, > >> and not count on it arriving in the same sized chunks as you wrote it. > >> But it will all arrive. > > > >This is (supposedly) what happens *for you* during packet reassembly > >on the receiving end. > > No; what happens for you at the receiving end is that the packets get > reassembled into the same *stream* of data as they were at the sender. > The sender can buffer small writes into big chunks, or can fragment big > writes. If the underlying MTU of the path changes, writes that didn't > used to have to be fragmented may now have to be. Packet N can get > lost in the network, while packets N+1, N+2, N+3 and N+4 arrive; when > the sender retransmits packet N all of a sudden a ton of data "shows > up" at the receiver. The receiver's job is *solely* to put those > packets back together into the same stream as the sender sent. So at the "read" interface, you *can* count on it arriving in the same sized chunks as you wrote it, as long as the order and chunk size of your reads is identical to those of your writes... in other words, synchronized client and server automatons. Right? IF I issue a blocking read for 1000 bytes, AND I issue a blocking write for 1000 bytes, AND the blocking write returns "1000", THEN the blocking read will return 1000 bytes OR it won't return (EPIPE after connection timeout). Karl is saying he has synchronized client and server automatons, but that it's not working for large buffer sizes on the writes. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.