On Tue, Jul 1, 2014 at 2:00 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > In message < > CAP+FsNfx5bO+W5sOEnVj5TJPqZbW-yND2Xo3Tu7nycV_zSaSxA@mail.gmail.com>, > Roberto Peon writes: > > >So, essentially, the bug here would be on the side that isn't reading, > >regardless of the endpoint being client or server. > > > >Any side which ceases reading/examining received bytes can cause the > >session to enter into a deadlock state. > > How would that ever work ? > > To send any data you need to receive WINDOW updates, so there is no > way to stop paying attention to incoming frames and expect things to > work in any way. > Correct. If an endpoint doesn't want to receive more data, it needs to set max streams to zero, flow control to zero, etc. Even then, it needs to read from the socket in order to respond appropriately to PING, WINDOW_UPDATE, SETTINGS etc. An HTTP2 endpoint must always be attempting to read from the socket. It must always (eventually) read the amount of data it promised w.r.t. its flow control window if it is to avoid deadlock. It can always throw it away and RST the stream, however. -=R > The most likely way that could happen is mutual TCP window lockout, > but that can only happen if boths sides are either primitively > half-duplex or broken in some other way. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. >
Received on Tuesday, 1 July 2014 21:10:59 UTC