[vlc-devel] live555 connection timeout (patch included)

[Rémi Denis-Courmont]

On Tue, 7 Oct 2008 23:42:34 +0200, Derk-Jan Hartman <hartman at videolan.org>
wrote:
>> 1. change i_lefttries from 3 to 1. As Sebastien remarqued, I don't
>> know why we want to retry 3 times and take 3 times as much time to
>> return. The user can retry manually if he wants to. I am sure he would
>> rather retry himself than wait longer.

For the RTSP control connection or for data?

I personally think that retrying TCP connection (without the user asking)
is evil. TCP handshake has built-in SYN and SYN/ACK retransmissions to deal
with packet loss anyway.

This leaves the case that the server sends a RST packet. Which means the
server is off. Which means you should not try to reconnect unless the
client asks.

On the other hand, many people keep asking for http-reconnect to be
"fixed", so I can imagine the same requests coming for RTSP.

> This is for an initial authentication failure basically, and for  
> rollover to TCP i think.

So it reconnects the control connection to rollover to TCP? That would seem
stupid.

>> 2. In the Connect member, if p_sys->rtsp->sendOptionsCmd fails
>> p_sys->rtsp->describeURL is called anyway. both of these call
>> openConnectionFromURL. It would seem that if
>> p_sys->rtsp->sendOptionsCmd fails, p_sys->rtsp->describeURL could be
>> skipped. This saves waiting for another openConnectionFromURL to fail.
> 
> Possibly, but i'm a tad weary on this.

In theory, it should work, but if it makes the messy/buggy
liblive555_plugin state machine even more complicated, then err...

> The live555 code should be fixed, or better, we should dump live555  
> and implement RTSP in VLC. (so we also get ipv6 support).
> We can discuss this to the moon, but ultimately, those are the best  
> two options. There is one question to ask, and that is who's is gonna  
> do the coding work.

I agree.

-- 
Rémi Denis-Courmont