From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 23 23:48:41 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B78DA8F4 for ; Tue, 23 Jul 2013 23:48:41 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 9662E2D24 for ; Tue, 23 Jul 2013 23:48:41 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 3DFEC3B615 for ; Tue, 23 Jul 2013 16:48:33 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-hackers@freebsd.org Subject: Re: bin/176713: [patch] nc(1) closes network socket too soon In-Reply-To: Date: Tue, 23 Jul 2013 16:48:33 -0700 Message-ID: <11109.1374623313@server1.tristatelogic.com> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 23:48:41 -0000 In message Adrian Chadd 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