[vlc-devel] [PATCH 2/2] chromecast: don't close the client connection

[Pierre Ynard]

> Actually «sufficiently high» doesn't make sense for this case. Systems
> have maximum values and an error code associated to that.

Well obviously the best you can do is attempt to set the most
appropriate value within whatever the available range is, on systems
where any such configuration is even possible.

That said, at this point I haven't seen it confirmed that the TCP
timeout was ever an issue here; and it would still have to be tested
whether any socket option has the intended effect here, since we're not
exactly in the typical case of an unresponsive, unreachable client.

> The point raised by François shed light on the timeout points: if the
> client isn't keepalive-aware or hasn't a higher enough timer value it
> could timeout as well, so this higher timeout value is useless without
> a testing/dump on the chromecast to know the value/check whether
> keepalive even makes sense.

It's not really reflexive, it's more one-way on each side; and indeed if
the network in between really goes down, each side can only rely on its
own settings without influence from the other side to decide when it's
going to drop the connection and move on.

Unless you're talking about another, third issue, the problem here if I
understand correctly is how long the server's TCP send buffer remains
full of data or stalled, because it can't transmit that data to the
client, because the client's TCP receive buffer is full, because the
client application isn't reading that data from the socket. How long the
server waits before giving up is a decision that belongs solely to the
server side, either application or TCP stack.

The client can have its own TCP settings about how and how much data it
accepts and acknowledges, and more importantly the client application
controls how long it takes to read the data, but they still don't decide
when the server gives up. The only thing the client could do would be to
reset (brutally terminate) the connection, but I can't see why it would
do that since it's not waiting on the server for anything, quite the
contrary.

> It also joins the point raised multiple times which suggests the bug
> should be solved elsewhere. Since Chromecast and its waiting callback
> has been incriminated, maybe some points can be expanded here in the
> design of the url callback?

Well blocking in a non-blocking callback certainly sounds wrong, and
waiting for a certain amount of data to return certainly seems curious,
but the way I understand it, fixing the callback isn't going to solve
the timeout issue caused by the client not reading data in a timely
fashion - unless they're connected in some way, but I don't see how.
However, fixing the timeout issue will restore functionality, and as
long as Chromecast is segregated to its own port and HTTPd thread, the
blocking callback is not an immediate concern.

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."