Date: Mon, 29 Jul 2013 09:42:13 -0600 From: Ian Lepore <ian@FreeBSD.org> To: "Ronald F. Guilmette" <rfg@tristatelogic.com> Cc: freebsd-hackers@FreeBSD.org Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon Message-ID: <1375112533.45247.43.camel@revolution.hippie.lan> In-Reply-To: <11109.1374623313@server1.tristatelogic.com> References: <11109.1374623313@server1.tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2013-07-23 at 16:48 -0700, Ronald F. Guilmette wrote: > 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. > I don't think this accurately summarizes things. The view of the remote server isn't just "EOF arrives" it's "can't read anymore" and "can't write anymore" which have to be handled separately. > 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. > Here you seem to be talking about the inability to send more data to the remote side. If you exit immediately when that happens, even if you could still read from the remote side, then you may miss the incoming data that would tell you why you can't send anymore. In this case the thing to do would be to stop reading stdin, but continue to read the remote side and copy it to stdout until you get EOF reading the remote side. Conversely, you can't exit immediately when the remote side has no more to send you and shuts down that half of the connection, you still have to read from stdin and send it to the remote until EOF on stdin or the remote shuts down that half of the connection. How all this applies to netcat's ability to do connectionless (UDP) stuff probably makes the whole thing that much more interesting. BTW, earlier in the thread you asserted more or less that telnet is for interactive and nc for scripting. I virtually never use nc in any way except interactively, and I use it that way every day, all day long. -- Ian > 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1375112533.45247.43.camel>