[vlc-devel] [PATCH] Enhancements to use asynchronous requests and persistent random access to improve http seek

[Bill C. Riemers]

Rémi Denis-Courmont wrote:
> Le mardi 17 juin 2008 21:09:30 Bill C. Riemers, vous avez écrit :
>   
>> For the most part this is the same as my previous patch.  I just merged
>> the conflicts from the revised patch for the seek bug fix and the patch
>> not to send a negative byte range.
>>     
>
> Unfortunately, the HTTP access is very messy (you must have noticed that by 
> now). I am a bit concerned that making supplementary requests even when we 
> don't actually seek might not be appreciated by server dudes.
>   
In theory, the whole point of http 1.1 is to be able to make many small
requests exactly as
the patch is doing.   Whether or not admins like it is another
question.   For example, when
I changed Java DjVu to use http 1.1 the number of hits on my server shot
up tremendously.
However, when I look at overall number of bytes transfer, it is much
less because far less
unnecessary  data is being transmitted.

However, I really would like to get this right.
> More importantly, what happens if the URL refers to a "continuous" 
> (non-seekable) stream, such as an MP3 radio? it is not entirely clear to me 
> from reading the patch.
>   
Hmmm.   If I read the specs correctly, in that case the server is
suppose to ignore the range
request and respond with 200 and send the full stream.  The stream size
is set to -1, the rest
of the code for multiple requests is bypassed.

However, if we really want to bullet proof the code, then it might be a
good idea to change
the condition for sending a range request from:

if ( p_sys->i_version == 1)

to

if ( p_sys->i_version == 1 && ! p_sys->b_continuous )

Then we don't have to rely on the server doing the right thing for a
non-seekable stream.

One fringe case that exists both with and without this patch, is when I
read the http 1.1 specs,
it looks like the server does not have to implement Range requests.  It
can just ignore the range of
the requests and always respond with the full stream (200).   In that
case, we have the problem
that the stream is marked seek-able, but it is not.   I don't know of
any servers which actually do this.

Bill