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.fors...@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.fors...@gmail.com> 
>> wrote:
>>> On 5 February 2017 at 05:23, Bakul Shah <ba...@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".

Reply via email to