[dancer-users] Detecting disconnected HTTP clients during streamed output
Nicola Worthington
nicolaw at tfb.net
Sun Dec 22 16:11:26 GMT 2013
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/104f61be/attachment-0001.html>
More information about the dancer-users
mailing list