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--