Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.glorb.com!news-out.octanews.net!indigo.octanews.net!news-2.mpls.iphouse.net.POSTED!not-for-mail From: David Dyer-Bennet Newsgroups: comp.os.linux.development.apps Subject: Re: EOF, close(), shutdown(), on POSIX sockets References: <20120105155657.311@kylheku.com> Date: Fri, 06 Jan 2012 09:59:33 -0600 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (usg-unix-v) Cancel-Lock: sha1:M9sdu0USBc8AATyKngISDYG0g+s= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 80 Organization: ipHouse - Welcome Home! NNTP-Posting-Date: 06 Jan 2012 09:59:33 CST NNTP-Posting-Host: f48eb17e.newsreader.iphouse.net X-Trace: DXC=JB01lX:oQXMAnIREHOgFaNVn\Tj8`^BbKeHS>e[L>83@gZ@;>V08<2MWX@ab@3=d:@mbdiTPUBI>N>03M14C\`8N X-Complaints-To: abuse@iphouse.net Xref: x330-a1.tempe.blueboxinc.net comp.os.linux.development.apps:358 Kaz Kylheku writes: > On 2012-01-05, David Dyer-Bennet wrote: >> If I receive EOF when I read from A, I think I should do shutdown(B, >> SHUT_WR), and if I receive EOF when I read from B, I should similarly do >> shutdown (A, SHUT_WR). > > Indeed, if you want the proxy in the middle to be transparent to half-closes, > which is a wortwhile requirement to implement if you want it to be as > transparent as possible. Thanks for the confirmation. My concept is to make the backend of the proxying, after the initial load-balancing and routing, as transparent as possible. >> 17:58:48.764575 shutdown(3, 0 /* receive */) = 0 >> >> nc promptly shuts down the socket it just received EOF on. Should I be >> doing this in addition to the other? > > This is not necessary, and SHUT_RD can basically be even regarded > as useless in TCP communication. > > Look in net/ipv4/tcp_ipv4.c in the tcp_shutdown function. It bails out > if it's not in the write direction: > > if (!(how & SEND_SHUTDOWN)) > return; > > Shutting down for reading is basically nonsensical; don't waste cycles > tripping into the kernel for this. I really should get more used to digging into the source on these, thanks. I'm not used to looking at Linux kernel source enough. >> Another confusing factor: immediately after this, nc reads 1024 bytes >> from stdin (leaving it in the middle of the test file, about 56%; and >> that's only 1/8 of the amount of data requested), writes it to 3, then >> closes and exits -- meaning it aborts reading and transmitting the input >> file. > > I've just looked at four different variants of netcat source code. (From this I can gather that you're running the one from the netcat-openbsd package.) What I know is that I'm using the package nc-1.84-10.fc6 for Centos 5. Took me a while to figure oout thta the name "netcat" wasn't what was going to get me anything in their repository. > I looked at the repository for GNU netcat, openbsd-netcat some original > netcat sources from "hobbit@avian.org", as well as the NMAP project's > netcat-like program. > > All of them bail their loop on EOF from the socket. > > This is probably because the typical use case for netcat is to do a > one-directional transfer, in the absence of any kind of request/response > transaction. One side dumps data into the socket, the other dumps it > into a file. When EOF is detected from the network, of course all previously > received data has been written, and the sender is not expecting anything > in return. > > Half-close logic is required for correctly implementing two-way transactions, > whereby the client indicates "I have no more requests for the server", > but not all the responses have been received. > > So these netcat utilities do not seem to provide a complete test case for a > proxy's transparent handling of half close. Try proxying some true > client/server protocols. (HTTP? RDBMS's? ...) Excellent. So I don't have to worry about that. It's the one glitch I seem to have in my behavior (that my current tests find). I've run other tests using some simple protocols I wrote myself. I could certainly arrange to use some real ones as well, I should do that. Thanks very much for your exceedingly clear and complete response! -- David Dyer-Bennet, dd-b@dd-b.net; http://dd-b.net/ Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ Photos: http://dd-b.net/photography/gallery/ Dragaera: http://dragaera.info