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