[dancer-users] Detecting disconnected HTTP clients during streamed output
Nicola Worthington
nicolaw at tfb.net
Sun Dec 22 16:12:39 GMT 2013
Typo: client has DISconnected or timed out
On Dec 22, 2013 4:11 PM, "Nicola Worthington" <nicolaw at tfb.net> wrote:
> I'm not sure I understand what you're saying here. I think we might have
> our wires crossed or I've not explained myself very well.
>
> Web servers communicate over TCP. Therefore until the point that either
> the servers established TCP connection detects that the client has
> connected or timed out, it will be able to tell how much data has been
> successfully send and acknowledged as received by the client browser. This
> is a function of the underlying TCP network connection. I'm simply looking
> for a way to get at this socket level information as exposed to the PSGI
> application through the web server.
> On Dec 22, 2013 3:57 PM, "Daniel Perrett" <dperrett at cambridge.org> wrote:
>
>> As far as I understand it, this is impossible with any HTTP server,
>> because once a client makes an HTTP request, the server processes it and
>> responds - and there is no communication between them in the mean time. A
>> server has no way of knowing if the client is still interested, and the
>> server cannot initiate contact with the client. You could pull some tricks
>> to demand multiple HTTP requests (generate 3xx responses on the fly to play
>> for time), but this is likely to be a headache, and from the sounds of it
>> won't fit your use case either. WebSockets might help you, but I don't know
>> much about them, and I don't think it will work if you don't have any
>> control over the client.
>>
>> To me it sounds like the root of the problem is you are offering to do
>> resource-intensive tasks for unidentifiable users where the only thing you
>> know about them is that they have the URL.
>>
>> Daniel
>>
>> -----dancer-users-bounces at dancer.pm wrote: -----
>> To: Perl Dancer users mailing list <dancer-users at dancer.pm>
>> From: Nicola Worthington
>> Sent by: dancer-users-bounces at dancer.pm
>> Date: 12/21/2013 12:57PM
>> Subject: Re: [dancer-users] Detecting disconnected HTTP clients during
>> streamed output
>>
>> That's certainly a possibility, but since this app is primarily aimed at
>> mobile devices that will be landing directly on stream URLs (for the most
>> part not launched from their browser but through a handful of other apps
>> that will simply make a call to the OS to open a URL for them to stream
>> media directly) it would make this approach less than idea and not as
>> robust as I was hoping for. :(
>>
>>
>> On 21 December 2013 03:52, Matthew Mallard <mqm at q-technologies.com.au>wrote:
>>
>>> Just an idea.
>>>
>>> Why don't you use ajax and only allow on conversion per user at a time.
>>> You can create an ajax query to check on progress, plus the user can
>>> cancel. Basically detach the conversion from the web client, but allow
>>> client to check on progress and have access to the file when it has
>>> finished.
>>>
>>>
>>> On 21/12/2013 5:40 am, Nicola Worthington wrote:
>>>
>>> I have a handler that transcodes video files using ffmpeg which all
>>> works fine. However, if the web client disconnects or otherwise stops
>>> reading from the socket, my handler will continue reading from the ffmpeg
>>> filehandle and writing out to the writer object until ffmpeg has completed
>>> the transcode.
>>>
>>> This wouldn't be a problem is we lived in a perfect world where every
>>> web client would send a single request to a URL and not make additional
>>> requests until the first one had been completed, but of course we don't
>>> live in an ideal world,.. and I would prefer my webapp not kill the server
>>> it is running on my spawning off more CPU intensive processes than
>>> necessary.
>>>
>>> Is there any way for me to determine how much data is sat waiting to
>>> be flushed to the web client so that if it exceeded a predetermined number
>>> of bytes I can assume that I should kill my ffmpeg file handle and exit the
>>> handler prematurely,.. or any other way to determine if the web client has
>>> gone away?
>>>
>>> Apologies if I haven't explained myself especially articulately.
>>>
>>> This is the handler in question:
>>>
>>> *get '/stream/:file/:format' => sub {*
>>> * my $file = params->{file};*
>>> * my $format = params->{format};*
>>>
>>> * return send_file(*
>>> * 'favicon.ico',*
>>> * streaming => 1,*
>>> * callbacks => {*
>>> * override => sub {*
>>> * my ($respond, $response) = @_;*
>>>
>>> * my $mime = 'video/mp4';*
>>> * my @ffmpeg_args = qw(-threads 0 -i $file);*
>>>
>>> * if (exists $ffmpeg_formats{$format}) {*
>>> * $mime = 'video/' . $format;*
>>> * push @ffmpeg_args, @{$ffmpeg_formats{$format}};*
>>> * } else {*
>>> * push @ffmpeg_args, @{$ffmpeg_formats{mp4}};*
>>> * }*
>>> * push @ffmpeg_args, '-';*
>>>
>>> * my $writer = $respond->([200, ['Content-Type' =>
>>> $mime]]);*
>>> * open(my $fh, '-|', join(' ', '/usr/bin/ffmpeg',
>>> @ffmpeg_args));*
>>> * my $buffer;*
>>> * while (read($fh, $buffer, 1024) ) {*
>>> * $writer->write($buffer);*
>>> * }*
>>> * close($fh);*
>>> * },*
>>> * },*
>>> * );*
>>> *};*
>>>
>>>
>>> --
>>> Nicola Worthington
>>> nicolaw at tfb.net
>>>
>>>
>>>
>>> _______________________________________________
>>> dancer-users mailing list
>>> dancer-users at dancer.pm
>>> http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
>>>
>>>
>>>
>>> _______________________________________________
>>> dancer-users mailing list
>>> dancer-users at dancer.pm
>>> http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
>>>
>>>
>>
>>
>> --
>> Nicola Worthington
>> +44 (0)3333 406 333
>> nicolaw at tfb.net
>>
>> _______________________________________________
>> dancer-users mailing list
>> dancer-users at dancer.pm
>> http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
>>
>> _______________________________________________
>> dancer-users mailing list
>> dancer-users at dancer.pm
>> http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.preshweb.co.uk/pipermail/dancer-users/attachments/20131222/ebcf0395/attachment.html>
More information about the dancer-users
mailing list