Date: Wed, 24 Jul 2013 01:00:00 GMT From: Mark Linimon <linimon@lonesome.com> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon Message-ID: <201307240100.r6O100Br046261@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/176713; it has been noted by GNATS. From: Mark Linimon <linimon@lonesome.com> To: bug-followup@FreeBSD.org Cc: Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon Date: Tue, 23 Jul 2013 19:59:41 -0500 ----- Forwarded message from "Ronald F. Guilmette" <rfg@tristatelogic.com> ----- Date: Tue, 23 Jul 2013 16:48:33 -0700 From: "Ronald F. Guilmette" <rfg@tristatelogic.com> To: freebsd-hackers@freebsd.org Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon In message <CAJ-Vmonk-8v9ej0w4qycNNBkieOeE9dL3BTVp6VqipxKH2jSUA@mail.gmail.com> Adrian Chadd <adrian@freebsd.org> wrote: >Right, and your patch just stops the shutdown(), right? The shutdown that occurs when EOF is encountered on stdin, yes. >Rather than >teaching nc to correctly check BOTH socket states before deciding to >close things. In effect, nc *is* currently "checking both sockets" and that is exactly the problem. It terminates (prematurely in some cases) whenever it sees an EOF _either_ from the remote host _or_ from stdin. My patch casuses nc to wait for EOF from the remote server before exiting, EVEN IF prior to the time it sees that EOF from the remote server it sees an EOF (first) on stdin. This code change demonstratably makes the functionality of nc better and more pragmatically useful in typical use cases. You appear to be proposing something else, but I'm sorry to say that I cannot decypher what, exactly you are attempting to propose. I have proposed specific code changes. If you have some different ones that you would like to propose, then I feel sure that everyone on the hackers list, including myself, would be interested to take a look at what you have in mind, and also what problem you are solving. >I'd personally rather see nc taught to check to see whether it can >possibly make ANY more progress before deciding to shut things down. I believe that that is exactly what the patch that I proposed does. I'm not sure why you feel otherwise. Look, there are only two scenarios... either (a) EOF arrives from stdin first or else (b) EOF arrives from the remote server first. My patch causes nc to continue gathering data from the remote server (and copying it all to stdout) in case (a). In case (b) there is no point in nc continuing to run (and/or continuing to read from stdin) if the remote server has shut down the connection. In this case, the data that nc might yet gather from its stdin channel has noplace to go! So whenever nc has sensed an EOF from the remote server it can (and should) immediately shut down... and that is exactly what it is _already_ programmed to do. So, what problem do you want to solve that is not solved by the patch that I already proposed? Also, with respect, if you think there really is some other problem, then proposing actual concrete patches to solve that other problem would perhaps allow folks, including myself, to better understand what it is that you are driving at. Regards, rfg _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" ----- End forwarded message -----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201307240100.r6O100Br046261>