From owner-freebsd-hackers Fri Nov 15 13:48:17 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA19422 for hackers-outgoing; Fri, 15 Nov 1996 13:48:17 -0800 (PST) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA19417 for ; Fri, 15 Nov 1996 13:48:14 -0800 (PST) Received: from Mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.8.2/8.8.2) with ESMTP id PAA17873; Fri, 15 Nov 1996 15:46:48 -0600 (CST) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Mailbox.mcs.com (8.8.2/8.8.2) with ESMTP id PAA03963; Fri, 15 Nov 1996 15:46:45 -0600 (CST) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.2/8.8.2) id PAA10779; Fri, 15 Nov 1996 15:46:43 -0600 (CST) From: Karl Denninger Message-Id: <199611152146.PAA10779@Jupiter.Mcs.Net> Subject: Re: Sockets question... To: terry@lambert.org (Terry Lambert) Date: Fri, 15 Nov 1996 15:46:43 -0600 (CST) Cc: fenner@parc.xerox.com, terry@lambert.org, scrappy@ki.net, jdp@polstra.com, hackers@freebsd.org In-Reply-To: <199611151858.LAA26626@phaeton.artisoft.com> from "Terry Lambert" at Nov 15, 96 11:58:51 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > 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. No, Karl is doing this: 1) The *writer* is writing records of variable size with a prefix to indicate how many byte(s) follow. 2) The writer does this ASSUMING that all of the records will get delivered to the reader. 3) When the writer is done, he writes a "no more records follow" flag record. 4) All of those writes return with no errors. 5) The READER gets about 2700 of the records (out of 8500!) and NEVER SEES ANY MORE DATA. It hangs in read()! This does NOT happen with the 2.6.3 development kit and libraries. It RELIABLY happens with -current. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 33 Analog Prefixes, 13 ISDN, Web servers $75/mo Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal