For the shut_rd case, I think a cleane= r 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 m= oment 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 wo= rking on a packet level network proxy. No access to that code now so the above is f= rom 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 transit= ion 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-en= d (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 mess= ages in tcpctl (/sys/src/9/ip/tcp.c). Then, roughly something like this:

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

c= ase 'shut_wr':
if (Established) {
=
qhangup(wq);
send(FIN)
tc= psetstate(Finwait_1)
}

=

= --Apple-Mail-BEECE8EC-96A8-470B-846A-15809CB7A6B4-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: From: Charles Forsyth Date: Sat, 4 Feb 2017 09:58:39 +0000 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a1145b474591c270547b17136 Subject: Re: [9fans] adding TCP half-duplex close Topicbox-Message-UUID: b3525248-ead9-11e9-9d60-3106f5b1d025 --001a1145b474591c270547b17136 Content-Type: text/plain; charset=UTF-8 On 4 February 2017 at 01:56, Skip Tavakkolian 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 --001a1145b474591c270547b17136 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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

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

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

--001a1145b474591c270547b17136-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: From: Charles Forsyth Date: Sat, 4 Feb 2017 10:11:34 +0000 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a114d2c028860ea0547b19f7d Subject: Re: [9fans] adding TCP half-duplex close Topicbox-Message-UUID: b357c5ca-ead9-11e9-9d60-3106f5b1d025 --001a114d2c028860ea0547b19f7d Content-Type: text/plain; charset=UTF-8 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 wrote: > > On 4 February 2017 at 01:56, Skip Tavakkolian > 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 > --001a114d2c028860ea0547b19f7d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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

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

On 4 Febru= ary 2017 at 01:56, Skip Tavakkolian <skip.tavakkolian@gmail.com> wrote:
Shutting down the wr= ite-end (i.e. 'shut_wr'), should send FIN, and transition to Finwai= t1.

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

--001a114d2c028860ea0547b19f7d-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: From: Charles Forsyth Date: Sat, 4 Feb 2017 10:13:11 +0000 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a114b114c4d58390547b1a5a0 Subject: Re: [9fans] adding TCP half-duplex close Topicbox-Message-UUID: b35d6746-ead9-11e9-9d60-3106f5b1d025 --001a114b114c4d58390547b1a5a0 Content-Type: text/plain; charset=UTF-8 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 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 > wrote: > >> >> On 4 February 2017 at 01:56, Skip Tavakkolian > > 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 >> > > --001a114b114c4d58390547b1a5a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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 w= ould pass a Java test but it was never otherwise used for reasons already g= iven, so I took it out again.

On 4 February 2017 at 10:11, Charles Forsyth <ch= arles.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 ot= her systems (data was flushed, or not) I gave it up as not particularly use= ful in practice, except between two known systems that did what you wanted.=
On 4 February 2017 at 09:58, Charles Forsyth <= span dir=3D"ltr"><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 &= quot;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

--001a114b114c4d58390547b1a5a0-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: In-Reply-To: From: Skip Tavakkolian Date: Sun, 5 Feb 2017 04:16:18 +0000 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=94eb2c0343e47a4f760547c0c71a Subject: Re: [9fans] adding TCP half-duplex close Topicbox-Message-UUID: b362d56e-ead9-11e9-9d60-3106f5b1d025 --94eb2c0343e47a4f760547c0c71a Content-Type: text/plain; charset=UTF-8 that makes sense. thanks. On Sat, Feb 4, 2017 at 5:38 AM Charles Forsyth wrote: > > On 4 February 2017 at 01:56, Skip Tavakkolian > 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 > --94eb2c0343e47a4f760547c0c71a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

that makes sense. thanks.

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

On 4 February 2017 at 01:56, Skip Tavakkolia= n <skip.tavakkolian@gmail= .com> wrote:
Shutting down the write-end (i.e. 'shut_wr'), shoul= d send FIN, and transition to Finwait1.

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

--94eb2c0343e47a4f760547c0c71a-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References:

In-Reply-To: From: Skip Tavakkolian Date: Sun, 5 Feb 2017 04:24:08 +0000 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=94eb2c09ab4a7487a90547c0e358 Subject: Re: [9fans] adding TCP half-duplex close Topicbox-Message-UUID: b3684e68-ead9-11e9-9d60-3106f5b1d025 --94eb2c09ab4a7487a90547c0e358 Content-Type: text/plain; charset=UTF-8 cool. On Fri, Feb 3, 2017 at 10:35 PM Bakul Shah 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 > 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) > } > > > --94eb2c09ab4a7487a90547c0e358 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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= =C2=A0proxy. 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 any= one looked into implementing this?=C2=A0 Can anyone comment on the details?=

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

As I underst= and 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).=C2=A0 Also, ther= e doesn't not seem to be consistency between different implementations = (Windows,Linux, *BSD) on what should happen to what's already in the re= ad queue; should it be allowed to drain to the reader or discarded immediat= ely?

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 message= s in tcpctl (/sys/src/9/ip/tcp.c). Then, roughly something like this:
=

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

case 'shut_w= r':
=C2=A0 if (Established) {
=C2=A0 =C2=A0 qhangup(wq);
=C2=A0 =C2=A0 send(FIN)
=C2=A0 =C2=A0 tcpset= state(Finwait_1)
=C2=A0 }

--94eb2c09ab4a7487a90547c0e358-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: In-Reply-To: From: Skip Tavakkolian Date: Sun, 5 Feb 2017 04:39:43 +0000 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a113deff432fab50547c11b09 Subject: Re: [9fans] adding TCP half-duplex close Topicbox-Message-UUID: b36e4cd2-ead9-11e9-9d60-3106f5b1d025 --001a113deff432fab50547c11b09 Content-Type: text/plain; charset=UTF-8 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 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 > 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 > wrote: > > > On 4 February 2017 at 01:56, Skip Tavakkolian > 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 > > > > --001a113deff432fab50547c11b09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

yes, i'm still trying to find a real situation where t= his 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@g= mail.com> wrote:

it's also funny that the rationale seems to b= e to pass the same conformance test for Go that once had it added to Infern= o 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 Feb= ruary 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 n= etwork 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 prac= tice, 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 T= avakkolian <skip.tavakkol= ian@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&qu= ot; parameter to the existing "hangup" message. older implementat= ions that don't accept the parameter will give an error on the request = because the current tcp.c doesn't accept a parameter

--001a113deff432fab50547c11b09-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bakul Shah Content-Type: multipart/alternative; boundary="Apple-Mail=_D3F94463-053E-4ABD-B9F3-D27653B3CA56" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Sat, 4 Feb 2017 21:23:10 -0800 References: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-Reply-To: Message-Id: Subject: Re: [9fans] adding TCP half-duplex close Topicbox-Message-UUID: b378bf0a-ead9-11e9-9d60-3106f5b1d025 --Apple-Mail=_D3F94463-053E-4ABD-B9F3-D27653B3CA56 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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=E2=80=99d use close(sock). At least I have not found a usecase when = I=E2=80=99d want to shutdown the read-end but continue sending on = write-end.=20 > On Feb 4, 2017, at 8:39 PM, Skip Tavakkolian = wrote: >=20 > 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. >=20 > On Sat, Feb 4, 2017 at 3:31 AM Charles Forsyth = > 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. >=20 > On 4 February 2017 at 10:11, Charles Forsyth = > 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. >=20 > On 4 February 2017 at 09:58, Charles Forsyth = > wrote: >=20 > On 4 February 2017 at 01:56, Skip Tavakkolian = > wrote: > Shutting down the write-end (i.e. 'shut_wr'), should send FIN, and = transition to Finwait1. >=20 > 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 >=20 >=20 --Apple-Mail=_D3F94463-053E-4ABD-B9F3-D27653B3CA56 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

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=E2=80=99d use close(sock). At least I = have not found a usecase when I=E2=80=99d 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> 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

= --Apple-Mail=_D3F94463-053E-4ABD-B9F3-D27653B3CA56-- From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/alternative; boundary=Apple-Mail-6852746D-2085-48AF-888A-B0FEF6DB304E Mime-Version: 1.0 (1.0) From: "Fran. J Ballesteros" In-Reply-To: Date: Sun, 5 Feb 2017 08:54:19 +0100 Content-Transfer-Encoding: 7bit Message-Id: <2E17A451-F68D-41A2-907B-ABFF797846C7@lsub.org> References: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] adding TCP half-duplex close Topicbox-Message-UUID: b37f86a0-ead9-11e9-9d60-3106f5b1d025 --Apple-Mail-6852746D-2085-48AF-888A-B0FEF6DB304E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I used half closes to put go chans in the network for my weird chan based ne= twork calls.=20 But the code works without such feature.=20 Being just that, I dont know if it counts.=20 > El 5 feb 2017, a las 5:39, Skip Tavakkolian e= scribi=C3=B3: >=20 > yes, i'm still trying to find a real situation where this would be critica= l. i asked go-nuts list for production examples at the same time as the star= t of this thread. no answers yet. >=20 >> On Sat, Feb 4, 2017 at 3:31 AM Charles Forsyth wrote: >> it's also funny that the rationale seems to be to pass the same conforman= ce test for Go that once had it added to Inferno so it would pass a Java tes= t but it was never otherwise used for reasons already given, so I took it ou= t again. >>=20 >> On 4 February 2017 at 10:11, Charles Forsyth w= rote: >> I did once have a use for this in an o/s of mine, in a sort of network pi= pe 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, excep= t between two known systems that did what you wanted. >>=20 >> On 4 February 2017 at 09:58, Charles Forsyth w= rote: >>=20 >> On 4 February 2017 at 01:56, Skip Tavakkolian wrote: >> Shutting down the write-end (i.e. 'shut_wr'), should send FIN, and transi= tion to Finwait1. >>=20 >> i'd make it a "read" or "write" parameter to the existing "hangup" messag= e. older implementations that don't accept the parameter will give an error o= n the request because the current tcp.c doesn't accept a parameter >>=20 >>=20 --Apple-Mail-6852746D-2085-48AF-888A-B0FEF6DB304E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

I used half closes to put g= o chans in the network for my weird chan based network

calls. = ;

But the code works without such feature.

Being j= ust that, I dont know if it counts.

El 5 feb 2017, a las= 5:39, Skip Tavakkolian <sk= ip.tavakkolian@gmail.com> escribi=C3=B3:

yes, i'm still trying to find a real situat= ion where this would be critical. i asked go-nuts list for production exampl= es 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.fo= rsyth@gmail.com> wrote:
it's also funny that the rationale seems to b= e 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 al= ready given, so I took it out again.

On 4 Februar= y 2017 at 10:11, Charles Forsyth <<= a href=3D"mailto:charles.forsyth@gmail.com" class=3D"gmail_msg" target=3D"_b= lank">charles.forsyth@gmail.com> wrote:
I did once have a use for this in an o/s of mine, in a sort of network pip= e to servers, but it was so variably implemented by other systems (data was f= lushed, or not) I gave it up as not particularly useful in practice, except b= etween two known systems that did what you wanted.

On 4 February 2017 at 09:58, Charles Forsyth <= span dir=3D"ltr" class=3D"gmail_msg"><charles.forsyth@gmail.com> wrote:

On 4 February 2017 at 01:56, Skip Tavakkolian <skip.tavakkolian@gmail.com>= wrote:
Shutt= ing down the write-end (i.e. 'shut_wr'), should send FIN, and transition to = Finwait1.

i'd make it a "re= ad" or "write" parameter to the existing "hangup" message. older implementat= ions that don't accept the parameter will give an error on the request becau= se the current tcp.c doesn't accept a parameter

= --Apple-Mail-6852746D-2085-48AF-888A-B0FEF6DB304E-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References:

From: Charles Forsyth Date: Sun, 5 Feb 2017 15:51:11 +0000 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a114d2c02f5b2dd0547ca7b79 Subject: Re: [9fans] adding TCP half-duplex close Topicbox-Message-UUID: b384d3ee-ead9-11e9-9d60-3106f5b1d025 --001a114d2c02f5b2dd0547ca7b79 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5 February 2017 at 05:23, Bakul Shah 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= =E2=80=99d > use close(sock). At least I have not found a usecase when I=E2=80=99d wan= t 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". --001a114d2c02f5b2dd0547ca7b79 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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

I think shutdown(sock, SH= U_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=E2=80=99d use close(sock). At least I h= ave not found a usecase when I=E2=80=99d want to shutdown the read-end but = continue sending on write-end.=C2=A0

Y= es. That's roughly what I tried to do with my network pipe, but at leas= t 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 en= d I had to add some protocol to ensure it, and didn't need the "fe= ature".

--001a114d2c02f5b2dd0547ca7b79-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References:

From: Charles Forsyth Date: Sun, 5 Feb 2017 15:54:04 +0000 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a1145ad88412b500547ca86d5 Subject: Re: [9fans] adding TCP half-duplex close Topicbox-Message-UUID: b38a9130-ead9-11e9-9d60-3106f5b1d025 --001a1145ad88412b500547ca86d5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 wrote: > > On 5 February 2017 at 05:23, Bakul Shah 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= =E2=80=99d >> use close(sock). At least I have not found a usecase when I=E2=80=99d wa= nt 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 e= nd > I had to add some protocol to ensure it, and didn't need the "feature". > --001a1145ad88412b500547ca86d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

It's a similar story with SYN+data+FIN to provide a ba= sic reliable datagram. You can't rely on a consistent implementation (u= nless 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:

Yes. That's roughly what I tried to do= with my network pipe, but at least at the time, target systems differed (a= s 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".

--001a1145ad88412b500547ca86d5-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bakul Shah Content-Type: multipart/alternative; boundary=Apple-Mail-1D505D54-5A53-42F7-8D37-F9BBED829933 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Sun, 5 Feb 2017 10:13:06 -0800 Message-Id: <7228BDDF-8FE9-4E7B-B1AE-4BD046B4B814@bitblocks.com> References:

In-Reply-To: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] adding TCP half-duplex close Topicbox-Message-UUID: b3934ff0-ead9-11e9-9d60-3106f5b1d025 --Apple-Mail-1D505D54-5A53-42F7-8D37-F9BBED829933 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable If they implement close correctly, they should be able to implement close-re= ad 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 rec= ent TCP roadmap RFC such as rfc7414! > On Feb 5, 2017, at 7:54 AM, Charles Forsyth wr= ote: >=20 > It's a similar story with SYN+data+FIN to provide a basic reliable datagra= m. You can't rely on a consistent implementation (unless it's to defeat your= purpose). >=20 >> On 5 February 2017 at 15:51, Charles Forsyth w= rote: >>=20 >>> On 5 February 2017 at 05:23, Bakul Shah wrote: >>> I think shutdown(sock, SHU_RD) is mainly to let the sender generate an S= IGPIPE 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=E2=80=99d use= close(sock). At least I have not found a usecase when I=E2=80=99d want to s= hutdown the read-end but continue sending on write-end.=20 >>=20 >> 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 t= o 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". >=20 --Apple-Mail-1D505D54-5A53-42F7-8D37-F9BBED829933 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

If they implement close correctly, the= y should be able to implement close-read correctly, it being a pure subset. I= n theory :-)

As for SYN+data+FIN you had to have both sides properly i= mplement rfc1644 or the T/TCP extension. This extension was deprecated at le= ast by 2004 due to "the ease of DoS attacks that can result". Might want to t= ake 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 w= ith SYN+data+FIN to provide a basic reliable datagram. You can't rely on a c= onsistent implementation (unless it's to defeat your purpose).

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

On 5 February 2017 at 05:23= , Bakul Shah <bakul@bitblocks.com> wrote:
I think shutdown(sock, SHU_RD) is mainly to let the send= er 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 y= ou=E2=80=99d use close(sock). At least I have not found a usecase when I=E2=80= =99d want to shutdown the read-end but continue sending on write-end. <= /div>
<= /div>

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

= --Apple-Mail-1D505D54-5A53-42F7-8D37-F9BBED829933-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <7228BDDF-8FE9-4E7B-B1AE-4BD046B4B814@bitblocks.com> References:

<7228BDDF-8FE9-4E7B-B1AE-4BD046B4B814@bitblocks.com> From: Charles Forsyth Date: Sun, 5 Feb 2017 21:48:18 +0000 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=94eb2c05f1541a8f880547cf7964 Subject: Re: [9fans] adding TCP half-duplex close Topicbox-Message-UUID: b3a75e8c-ead9-11e9-9d60-3106f5b1d025 --94eb2c05f1541a8f880547cf7964 Content-Type: text/plain; charset=UTF-8 On 5 February 2017 at 18:13, Bakul Shah 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. --94eb2c05f1541a8f880547cf7964 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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

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

but they didn't, so it's useless.

=C2=A0

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

<= br>

the original tcp/ip spec allowed for it, if implemented caref= ully (partly because of its heritage), but again, mismatch of implementatio= ns rendered it useless.

=C2=A0

This extension = was deprecated at least by 2004 due to "the ease of DoS attacks that c= an result".

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

--94eb2c05f1541a8f880547cf7964-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References:

<7228BDDF-8FE9-4E7B-B1AE-4BD046B4B814@bitblocks.com> In-Reply-To: From: Skip Tavakkolian Date: Fri, 10 Feb 2017 08:49:17 +0000 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a113deff4eb6caa0548292c0e Subject: Re: [9fans] adding TCP half-duplex close Topicbox-Message-UUID: b3acf9e6-ead9-11e9-9d60-3106f5b1d025 --001a113deff4eb6caa0548292c0e Content-Type: text/plain; charset=UTF-8 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 wrote: > On 5 February 2017 at 18:13, Bakul Shah 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. > > > --001a113deff4eb6caa0548292c0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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

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

<= div>Please review it; the change is fairly small.

= It would be great if others could try it out. I've done light testing w= ith rc.=C2=A0 I've also verified it passes Go's net/http/serve_test= .go (see=C2=A0https:/= /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. Pleas= e 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> wro= te:

On 5 February 2017 at 18:13, Bakul Shah <bakul@bitblocks.com> wrote:
If th= ey implement close correctly, they should be able to implement close-read c= orrectly, it being a pure subset. In theory :-)

but they didn't, so it's useless.
=C2=A0
As for SYN+data+FIN you had to have b= oth sides properly implement rfc1644 or the T/TCP extension.
<= /blockquote>

the = original tcp/ip spec allowed for it, if implemented carefully (partly becau= se of its heritage), but again, mismatch of implementations rendered it use= less.
=C2=A0
This extension was deprecated at least by 2004 due to "= ;the ease of DoS attacks that can result".
<= div class=3D"gmail_msg">
yes, that's e= xactly what meant there was no longer any point in trying.