[9fans] adding TCP half-duplex close

[9fans] adding TCP half-duplex close

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 1325 bytes --]

Has anyone looked into implementing this?  Can anyone comment on the
details?

For the curious, this is described here:
https://tools.ietf.org/html/rfc1122#page-87
Go net package (https://github.com/golang/go/issues/17906).

As I understand it, one would only worry about 'shutdown' if the connection
is in 'Established' state. It is not clear to me what the state should
transition to when the read-end is closed (i.e. shut_rd).  Also, there
doesn't not seem to be consistency between different implementations
(Windows,Linux, *BSD) on what should happen to what's already in the read
queue; should it be allowed to drain to the reader or discarded immediately?

Shutting down the write-end (i.e. 'shut_wr'), should send FIN, and
transition to Finwait1.

I think the correct mechanics to handle this would be to add two new
messages in tcpctl (/sys/src/9/ip/tcp.c). Then, roughly something like this:

case 'shut_rd' :
 if (Etablished) {
  qhangup(rq);
  send(RST);  // Windows does this and RFC1122 seems to recommend it. Linux
does not.
  tcb->rcv.blocked = 1;  // all that's needed?
  tcb->rcv.wnd = 0;
  tcpsetstate(????)  // not sure what it should be or should stay
Established?
}

case 'shut_wr':
  if (Established) {
    qhangup(wq);
    send(FIN)
    tcpsetstate(Finwait_1)
  }

[-- Attachment #2: Type: text/html, Size: 2398 bytes --]

Re: [9fans] adding TCP half-duplex close

[Bakul Shah]

[-- Attachment #1: Type: text/plain, Size: 1980 bytes --]

For the shut_rd case, I think a cleaner impl is to send RST *only* if there is pending data (received but not read by the user) or new data is received after the read end is closed. At the moment I don't recall what BSD does but you don't have to allow draining once the read end is closed. Just drain and RST! Any user reads should fail.

I recall having to deal with this in the past while working on a packet level network proxy. No access to that code now so the above is from memory.



Sent from my iPad
> On Feb 3, 2017, at 5:56 PM, Skip Tavakkolian <skip.tavakkolian@gmail.com> wrote:
> 
> Has anyone looked into implementing this?  Can anyone comment on the details?
> 
> For the curious, this is described here: https://tools.ietf.org/html/rfc1122#page-87
> Go net package (https://github.com/golang/go/issues/17906).
> 
> As I understand it, one would only worry about 'shutdown' if the connection is in 'Established' state. It is not clear to me what the state should transition to when the read-end is closed (i.e. shut_rd).  Also, there doesn't not seem to be consistency between different implementations (Windows,Linux, *BSD) on what should happen to what's already in the read queue; should it be allowed to drain to the reader or discarded immediately?
> 
> Shutting down the write-end (i.e. 'shut_wr'), should send FIN, and transition to Finwait1.
> 
> I think the correct mechanics to handle this would be to add two new messages in tcpctl (/sys/src/9/ip/tcp.c). Then, roughly something like this:
> 
> case 'shut_rd' : 
>  if (Etablished) {
>   qhangup(rq);
>   send(RST);  // Windows does this and RFC1122 seems to recommend it. Linux does not.
>   tcb->rcv.blocked = 1;  // all that's needed?
>   tcb->rcv.wnd = 0;
>   tcpsetstate(????)  // not sure what it should be or should stay Established?
> }
> 
> case 'shut_wr':
>   if (Established) {
>     qhangup(wq);
>     send(FIN)
>     tcpsetstate(Finwait_1)
>   }
> 
> 

[-- Attachment #2: Type: text/html, Size: 3375 bytes --]

Re: [9fans] adding TCP half-duplex close

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 2121 bytes --]

cool.

On Fri, Feb 3, 2017 at 10:35 PM Bakul Shah <bakul@bitblocks.com> wrote:

> For the shut_rd case, I think a cleaner impl is to send RST *only* if
> there is pending data (received but not read by the user) or new data is
> received after the read end is closed. At the moment I don't recall what
> BSD does but you don't have to allow draining once the read end is closed.
> Just drain and RST! Any user reads should fail.
>
> I recall having to deal with this in the past while working on a packet
> level network proxy. No access to that code now so the above is from
> memory.
>
>
>
> Sent from my iPad
> On Feb 3, 2017, at 5:56 PM, Skip Tavakkolian <skip.tavakkolian@gmail.com>
> wrote:
>
> Has anyone looked into implementing this?  Can anyone comment on the
> details?
>
> For the curious, this is described here:
> https://tools.ietf.org/html/rfc1122#page-87
> Go net package (https://github.com/golang/go/issues/17906).
>
> As I understand it, one would only worry about 'shutdown' if the
> connection is in 'Established' state. It is not clear to me what the state
> should transition to when the read-end is closed (i.e. shut_rd).  Also,
> there doesn't not seem to be consistency between different implementations
> (Windows,Linux, *BSD) on what should happen to what's already in the read
> queue; should it be allowed to drain to the reader or discarded immediately?
>
> Shutting down the write-end (i.e. 'shut_wr'), should send FIN, and
> transition to Finwait1.
>
> I think the correct mechanics to handle this would be to add two new
> messages in tcpctl (/sys/src/9/ip/tcp.c). Then, roughly something like this:
>
> case 'shut_rd' :
>  if (Etablished) {
>   qhangup(rq);
>   send(RST);  // Windows does this and RFC1122 seems to recommend it.
> Linux does not.
>   tcb->rcv.blocked = 1;  // all that's needed?
>   tcb->rcv.wnd = 0;
>   tcpsetstate(????)  // not sure what it should be or should stay
> Established?
> }
>
> case 'shut_wr':
>   if (Established) {
>     qhangup(wq);
>     send(FIN)
>     tcpsetstate(Finwait_1)
>   }
>
>
>

[-- Attachment #2: Type: text/html, Size: 4273 bytes --]

Re: [9fans] adding TCP half-duplex close

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 407 bytes --]

On 4 February 2017 at 01:56, Skip Tavakkolian <skip.tavakkolian@gmail.com>
wrote:

> Shutting down the write-end (i.e. 'shut_wr'), should send FIN, and
> transition to Finwait1.


i'd make it a "read" or "write" parameter to the existing "hangup" message.
older implementations that don't accept the parameter will give an error on
the request because the current tcp.c doesn't accept a parameter

[-- Attachment #2: Type: text/html, Size: 742 bytes --]

Re: [9fans] adding TCP half-duplex close

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 797 bytes --]

I did once have a use for this in an o/s of mine, in a sort of network pipe
to servers, but it was so variably implemented by other systems (data was
flushed, or not) I gave it up as not particularly useful in practice,
except between two known systems that did what you wanted.

On 4 February 2017 at 09:58, Charles Forsyth <charles.forsyth@gmail.com>
wrote:

>
> On 4 February 2017 at 01:56, Skip Tavakkolian <skip.tavakkolian@gmail.com>
> wrote:
>
>> Shutting down the write-end (i.e. 'shut_wr'), should send FIN, and
>> transition to Finwait1.
>
>
> i'd make it a "read" or "write" parameter to the existing "hangup"
> message. older implementations that don't accept the parameter will give an
> error on the request because the current tcp.c doesn't accept a parameter
>

[-- Attachment #2: Type: text/html, Size: 1425 bytes --]

Re: [9fans] adding TCP half-duplex close

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]

it's also funny that the rationale seems to be to pass the same conformance
test for Go that once had it added to Inferno so it would pass a Java test
but it was never otherwise used for reasons already given, so I took it out
again.

On 4 February 2017 at 10:11, Charles Forsyth <charles.forsyth@gmail.com>
wrote:

> I did once have a use for this in an o/s of mine, in a sort of network
> pipe to servers, but it was so variably implemented by other systems (data
> was flushed, or not) I gave it up as not particularly useful in practice,
> except between two known systems that did what you wanted.
>
> On 4 February 2017 at 09:58, Charles Forsyth <charles.forsyth@gmail.com>
> wrote:
>
>>
>> On 4 February 2017 at 01:56, Skip Tavakkolian <skip.tavakkolian@gmail.com
>> > wrote:
>>
>>> Shutting down the write-end (i.e. 'shut_wr'), should send FIN, and
>>> transition to Finwait1.
>>
>>
>> i'd make it a "read" or "write" parameter to the existing "hangup"
>> message. older implementations that don't accept the parameter will give an
>> error on the request because the current tcp.c doesn't accept a parameter
>>
>
>

[-- Attachment #2: Type: text/html, Size: 2084 bytes --]

Re: [9fans] adding TCP half-duplex close

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]

yes, i'm still trying to find a real situation where this would be
critical. i asked go-nuts list for production examples at the same time as
the start of this thread. no answers yet.

On Sat, Feb 4, 2017 at 3:31 AM Charles Forsyth <charles.forsyth@gmail.com>
wrote:

> it's also funny that the rationale seems to be to pass the same
> conformance test for Go that once had it added to Inferno so it would pass
> a Java test but it was never otherwise used for reasons already given, so I
> took it out again.
>
> On 4 February 2017 at 10:11, Charles Forsyth <charles.forsyth@gmail.com>
> wrote:
>
> I did once have a use for this in an o/s of mine, in a sort of network
> pipe to servers, but it was so variably implemented by other systems (data
> was flushed, or not) I gave it up as not particularly useful in practice,
> except between two known systems that did what you wanted.
>
> On 4 February 2017 at 09:58, Charles Forsyth <charles.forsyth@gmail.com>
> wrote:
>
>
> On 4 February 2017 at 01:56, Skip Tavakkolian <skip.tavakkolian@gmail.com>
> wrote:
>
> Shutting down the write-end (i.e. 'shut_wr'), should send FIN, and
> transition to Finwait1.
>
>
> i'd make it a "read" or "write" parameter to the existing "hangup"
> message. older implementations that don't accept the parameter will give an
> error on the request because the current tcp.c doesn't accept a parameter
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 3121 bytes --]

Re: [9fans] adding TCP half-duplex close

[Bakul Shah]

[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]

I think shutdown(sock, SHU_RD) is mainly to let the sender generate an SIGPIPE signal in case it has sent data on a closed direction of a connection. But I think this is only for completeness. Almost always you’d use close(sock). At least I have not found a usecase when I’d want to shutdown the read-end but continue sending on write-end. 

> On Feb 4, 2017, at 8:39 PM, Skip Tavakkolian <skip.tavakkolian@gmail.com> wrote:
> 
> yes, i'm still trying to find a real situation where this would be critical. i asked go-nuts list for production examples at the same time as the start of this thread. no answers yet.
> 
> On Sat, Feb 4, 2017 at 3:31 AM Charles Forsyth <charles.forsyth@gmail.com <mailto:charles.forsyth@gmail.com>> wrote:
> it's also funny that the rationale seems to be to pass the same conformance test for Go that once had it added to Inferno so it would pass a Java test but it was never otherwise used for reasons already given, so I took it out again.
> 
> On 4 February 2017 at 10:11, Charles Forsyth <charles.forsyth@gmail.com <mailto:charles.forsyth@gmail.com>> wrote:
> I did once have a use for this in an o/s of mine, in a sort of network pipe to servers, but it was so variably implemented by other systems (data was flushed, or not) I gave it up as not particularly useful in practice, except between two known systems that did what you wanted.
> 
> On 4 February 2017 at 09:58, Charles Forsyth <charles.forsyth@gmail.com <mailto:charles.forsyth@gmail.com>> wrote:
> 
> On 4 February 2017 at 01:56, Skip Tavakkolian <skip.tavakkolian@gmail.com <mailto:skip.tavakkolian@gmail.com>> wrote:
> Shutting down the write-end (i.e. 'shut_wr'), should send FIN, and transition to Finwait1.
> 
> i'd make it a "read" or "write" parameter to the existing "hangup" message. older implementations that don't accept the parameter will give an error on the request because the current tcp.c doesn't accept a parameter
> 
> 


[-- Attachment #2: Type: text/html, Size: 4029 bytes --]

Re: [9fans] adding TCP half-duplex close

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 736 bytes --]

On 5 February 2017 at 05:23, Bakul Shah <bakul@bitblocks.com> wrote:

> I think shutdown(sock, SHU_RD) is mainly to let the sender generate an
> SIGPIPE signal in case it has sent data on a closed direction of a
> connection. But I think this is only for completeness. Almost always you’d
> use close(sock). At least I have not found a usecase when I’d want to
> shutdown the read-end but continue sending on write-end.
>

Yes. That's roughly what I tried to do with my network pipe, but at least
at the time, target systems differed (as they were apparently allowed) as
to whether they reliably delivered data or simply flushed it, so in the end
I had to add some protocol to ensure it, and didn't need the "feature".

[-- Attachment #2: Type: text/html, Size: 1110 bytes --]

Re: [9fans] adding TCP half-duplex close

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 1010 bytes --]

It's a similar story with SYN+data+FIN to provide a basic reliable
datagram. You can't rely on a consistent implementation (unless it's to
defeat your purpose).

On 5 February 2017 at 15:51, Charles Forsyth <charles.forsyth@gmail.com>
wrote:

>
> On 5 February 2017 at 05:23, Bakul Shah <bakul@bitblocks.com> wrote:
>
>> I think shutdown(sock, SHU_RD) is mainly to let the sender generate an
>> SIGPIPE signal in case it has sent data on a closed direction of a
>> connection. But I think this is only for completeness. Almost always you’d
>> use close(sock). At least I have not found a usecase when I’d want to
>> shutdown the read-end but continue sending on write-end.
>>
>
> Yes. That's roughly what I tried to do with my network pipe, but at least
> at the time, target systems differed (as they were apparently allowed) as
> to whether they reliably delivered data or simply flushed it, so in the end
> I had to add some protocol to ensure it, and didn't need the "feature".
>

[-- Attachment #2: Type: text/html, Size: 1758 bytes --]

Re: [9fans] adding TCP half-duplex close

[Bakul Shah]

[-- Attachment #1: Type: text/plain, Size: 1476 bytes --]

If they implement close correctly, they should be able to implement close-read correctly, it being a pure subset. In theory :-)

As for SYN+data+FIN you had to have both sides properly implement rfc1644 or the T/TCP extension. This extension was deprecated at least by 2004 due to "the ease of DoS attacks that can result". Might want to take a look at a recent TCP roadmap RFC such as rfc7414!

> On Feb 5, 2017, at 7:54 AM, Charles Forsyth <charles.forsyth@gmail.com> wrote:
> 
> It's a similar story with SYN+data+FIN to provide a basic reliable datagram. You can't rely on a consistent implementation (unless it's to defeat your purpose).
> 
>> On 5 February 2017 at 15:51, Charles Forsyth <charles.forsyth@gmail.com> wrote:
>> 
>>> On 5 February 2017 at 05:23, Bakul Shah <bakul@bitblocks.com> wrote:
>>> I think shutdown(sock, SHU_RD) is mainly to let the sender generate an SIGPIPE signal in case it has sent data on a closed direction of a connection. But I think this is only for completeness. Almost always you’d use close(sock). At least I have not found a usecase when I’d want to shutdown the read-end but continue sending on write-end. 
>> 
>> Yes. That's roughly what I tried to do with my network pipe, but at least at the time, target systems differed (as they were apparently allowed) as to whether they reliably delivered data or simply flushed it, so in the end I had to add some protocol to ensure it, and didn't need the "feature".
> 

[-- Attachment #2: Type: text/html, Size: 2554 bytes --]

Re: [9fans] adding TCP half-duplex close

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 708 bytes --]

On 5 February 2017 at 18:13, Bakul Shah <bakul@bitblocks.com> wrote:

> If they implement close correctly, they should be able to implement
> close-read correctly, it being a pure subset. In theory :-)
>
>
but they didn't, so it's useless.


> As for SYN+data+FIN you had to have both sides properly implement rfc1644
> or the T/TCP extension.
>

the original tcp/ip spec allowed for it, if implemented carefully (partly
because of its heritage), but again, mismatch of implementations rendered
it useless.


> This extension was deprecated at least by 2004 due to "the ease of DoS
> attacks that can result".
>

yes, that's exactly what meant there was no longer any point in trying.

[-- Attachment #2: Type: text/html, Size: 1486 bytes --]

Re: [9fans] adding TCP half-duplex close

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 1318 bytes --]

I've submitted a patch for this to Bell Labs repo:

/n/sources/patch/tcp-halfduplex-close

Please review it; the change is fairly small.

It would be great if others could try it out. I've done light testing with
rc.  I've also verified it passes Go's net/http/serve_test.go (see
https://github.com/golang/go/issues/17906). All testing has been done with
RPI's (1's and 3's). I plan to do more testing with x86 box. Please try it
if you can.

Thanks everyone for your help,
-Skip

On Sun, Feb 5, 2017 at 1:48 PM Charles Forsyth <charles.forsyth@gmail.com>
wrote:

> On 5 February 2017 at 18:13, Bakul Shah <bakul@bitblocks.com> wrote:
>
> If they implement close correctly, they should be able to implement
> close-read correctly, it being a pure subset. In theory :-)
>
>
> but they didn't, so it's useless.
>
>
> As for SYN+data+FIN you had to have both sides properly implement rfc1644
> or the T/TCP extension.
>
>
> the original tcp/ip spec allowed for it, if implemented carefully (partly
> because of its heritage), but again, mismatch of implementations rendered
> it useless.
>
>
> This extension was deprecated at least by 2004 due to "the ease of DoS
> attacks that can result".
>
>
> yes, that's exactly what meant there was no longer any point in trying.
>
>
>

[-- Attachment #2: Type: text/html, Size: 3623 bytes --]

Re: [9fans] adding TCP half-duplex close

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 1489 bytes --]

It's not that simple. I'm still working on it.

On Fri, Feb 10, 2017 at 12:49 AM Skip Tavakkolian <
skip.tavakkolian@gmail.com> wrote:

> I've submitted a patch for this to Bell Labs repo:
>
> /n/sources/patch/tcp-halfduplex-close
>
> Please review it; the change is fairly small.
>
> It would be great if others could try it out. I've done light testing with
> rc.  I've also verified it passes Go's net/http/serve_test.go (see
> https://github.com/golang/go/issues/17906). All testing has been done
> with RPI's (1's and 3's). I plan to do more testing with x86 box. Please
> try it if you can.
>
> Thanks everyone for your help,
> -Skip
>
> On Sun, Feb 5, 2017 at 1:48 PM Charles Forsyth <charles.forsyth@gmail.com>
> wrote:
>
> On 5 February 2017 at 18:13, Bakul Shah <bakul@bitblocks.com> wrote:
>
> If they implement close correctly, they should be able to implement
> close-read correctly, it being a pure subset. In theory :-)
>
>
> but they didn't, so it's useless.
>
>
> As for SYN+data+FIN you had to have both sides properly implement rfc1644
> or the T/TCP extension.
>
>
> the original tcp/ip spec allowed for it, if implemented carefully (partly
> because of its heritage), but again, mismatch of implementations rendered
> it useless.
>
>
> This extension was deprecated at least by 2004 due to "the ease of DoS
> attacks that can result".
>
>
> yes, that's exactly what meant there was no longer any point in trying.
>
>
>

[-- Attachment #2: Type: text/html, Size: 4528 bytes --]

Re: [9fans] adding TCP half-duplex close

[Fran. J Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 1671 bytes --]

I used half closes to put go chans in the network for my weird chan based network
calls. 
But the code works without such feature. 
Being just that, I dont know if it counts. 

> El 5 feb 2017, a las 5:39, Skip Tavakkolian <skip.tavakkolian@gmail.com> escribió:
> 
> yes, i'm still trying to find a real situation where this would be critical. i asked go-nuts list for production examples at the same time as the start of this thread. no answers yet.
> 
>> On Sat, Feb 4, 2017 at 3:31 AM Charles Forsyth <charles.forsyth@gmail.com> wrote:
>> it's also funny that the rationale seems to be to pass the same conformance test for Go that once had it added to Inferno so it would pass a Java test but it was never otherwise used for reasons already given, so I took it out again.
>> 
>> On 4 February 2017 at 10:11, Charles Forsyth <charles.forsyth@gmail.com> wrote:
>> I did once have a use for this in an o/s of mine, in a sort of network pipe to servers, but it was so variably implemented by other systems (data was flushed, or not) I gave it up as not particularly useful in practice, except between two known systems that did what you wanted.
>> 
>> On 4 February 2017 at 09:58, Charles Forsyth <charles.forsyth@gmail.com> wrote:
>> 
>> On 4 February 2017 at 01:56, Skip Tavakkolian <skip.tavakkolian@gmail.com> wrote:
>> Shutting down the write-end (i.e. 'shut_wr'), should send FIN, and transition to Finwait1.
>> 
>> i'd make it a "read" or "write" parameter to the existing "hangup" message. older implementations that don't accept the parameter will give an error on the request because the current tcp.c doesn't accept a parameter
>> 
>> 

[-- Attachment #2: Type: text/html, Size: 3630 bytes --]

Re: [9fans] adding TCP half-duplex close

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 541 bytes --]

that makes sense. thanks.

On Sat, Feb 4, 2017 at 5:38 AM Charles Forsyth <charles.forsyth@gmail.com>
wrote:

>
> On 4 February 2017 at 01:56, Skip Tavakkolian <skip.tavakkolian@gmail.com>
> wrote:
>
> Shutting down the write-end (i.e. 'shut_wr'), should send FIN, and
> transition to Finwait1.
>
>
> i'd make it a "read" or "write" parameter to the existing "hangup"
> message. older implementations that don't accept the parameter will give an
> error on the request because the current tcp.c doesn't accept a parameter
>

[-- Attachment #2: Type: text/html, Size: 1321 bytes --]