On Sun, Nov 26, 2017 at 09:17:11PM +0100, Alexander Bluhm wrote:
> On Sun, Nov 26, 2017 at 03:52:33PM +0100, Klemens Nanni wrote:
> > nc as client keeps sending after the server shutdown the socket:
>
> Yes, that is a half closed connection. Server has shutdown, but
> client is still sending. This is a TCP feature made accessible by
> the nc tool.
Of course this is a valid scenario and I thought about my patch breaking
use cases where the server closes it's write end but continues/expects
to read more data from the client.
The reason I chose this behaviour is that nc(1)'s
-N shutdown(2) the network socket after EOF on the input.
Some servers require this to finish their work.
does not mention how it shuts down the socket in particular, e.g.
whether just SHUT_RD/SHUT_WR or SHUT_RDWR. As a reader I'd assume it to
shut both ends down and end the connection.
> > tedu@ introduced this with r1.125 (three years ago), r1.124 works as
> > expected just like telnet does for that matter:
>
> Who is expecting that 1.124 is the correct behavior?
Well, I (naively) did.
> > With the following diff nc will properly exit again as it used to.
>
> And why was this changed? Why are the reasons for r1.125 no longer
> valid?
That's a question I didn't ask but rather assumed it to be an undesired
change.
Was it an intentional change in behaviour?
> > Feedback?
>
> Which use case does your change fix?
The one where I expect netcat clients to exit upon netcat servers
shutting down the socket (as telnet does) due to my interpretation of
-N's description.
> Does -N also help in your case?
Not sure what you mean by that but using -N on both sides obviously does
not make the client exit.
> Which use cases does your diff break?
The unidirectional scenario described at the beginning is the only one
I've come up with so far but that's why I'm asking for feedback here.
If the current behaviour is indeed intended, I'd like to clarify -N's
description at least so that users can safely expect the server to
continue to read.
Thanks for your input :)