It's not that simple. I'm still working on it.
On Fri, Feb 10, 2017 at 12:49 AM Skip Tavakkolian <
skip.tavakkol...@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 gr
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/
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
>
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 Do
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
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’d
> use close(sock). At least I h
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
> escribió:
>
> yes, i'm still trying to find a real situation where thi
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
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 t
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
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 exis
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 on
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
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 erro
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
15 matches
Mail list logo