Date: Fri, 15 Nov 1996 15:46:43 -0600 (CST) From: Karl Denninger <karl@Mcs.Net> To: terry@lambert.org (Terry Lambert) Cc: fenner@parc.xerox.com, terry@lambert.org, scrappy@ki.net, jdp@polstra.com, hackers@freebsd.org Subject: Re: Sockets question... Message-ID: <199611152146.PAA10779@Jupiter.Mcs.Net> In-Reply-To: <199611151858.LAA26626@phaeton.artisoft.com> from "Terry Lambert" at Nov 15, 96 11:58:51 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611152146.PAA10779>