Hi Ray On Fri, Oct 24, 2014 at 10:09:39AM +0000, Ray Bellis wrote: > There are several outstanding questions therein - some relating to TCP > state where I don’t know the technical answer, and a couple where > opinions from the WG would be welcomed. The latter mostly relate to > whether it’s useful to define a request-side semantic for the proposed > flag in addition to the response-side semantics already written.
This is not a review of the draft, though the method seems simple enough
that the main decision is whether to add such a bit or not.
> TODO: does it make sense to specify a request side meaning for this
> flag, indicating that the server may half-close its "read" side of
> the connection? This would make the semantics even closer to those
> of the HTTP/1.1 "Connection: close" header (see Section 14.10 of
> [RFC2616]).
TCP doesn't have a half-close of the read side. See below.
> TODO: if a request-side semantic is defined for this flag, what are
> the TCP state-maintenance implications if the server performs a
> 'shutdown(fd, SHUT_RD)'?
This would be implementation specific. TCP being full-duplex, a TCP can
half-close only its writing end of the connection which is to say it
sends a FIN to the other side to indicate it is done and does not have
any more data to send. The other end of the connection can only be
closed by the other TCP. Even after sending a FIN during an active close
and having it ACKd by the other side, the sender could be stuck in the
FIN_WAIT_2 state for a long time until the other side closes its end of
the connection. (Operating systems timeout after a while.)
How do operating systems handle shutdown(..., SHUT_RD) on TCP sockets?
1. The TCP could send RST to the other side if it receives any further
segments on such a socket.
2. The OS could simply ignore such a shutdown(), and the unread data
accumulating (assuming the application doesn't read from the fd anymore)
would then reduce the receive window to 0 and flow control the sender to
stop transmissing.
3. The TCP could send ACKs and just discard the received data.
Mukund
pgpfsBPTz1CJj.pgp
Description: PGP signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
