Typo: client has DISconnected or timed out On Dec 22, 2013 4:11 PM, "Nicola Worthington" <[email protected]> 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" <[email protected]> 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 >> >> [email protected] wrote: ----- >> To: Perl Dancer users mailing list <[email protected]> >> From: Nicola Worthington >> Sent by: [email protected] >> 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 <[email protected]>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 >>> [email protected] >>> >>> >>> >>> _______________________________________________ >>> dancer-users mailing list >>> [email protected] >>> http://lists.preshweb.co.uk/mailman/listinfo/dancer-users >>> >>> >>> >>> _______________________________________________ >>> dancer-users mailing list >>> [email protected] >>> http://lists.preshweb.co.uk/mailman/listinfo/dancer-users >>> >>> >> >> >> -- >> Nicola Worthington >> +44 (0)3333 406 333 >> [email protected] >> >> _______________________________________________ >> dancer-users mailing list >> [email protected] >> http://lists.preshweb.co.uk/mailman/listinfo/dancer-users >> >> _______________________________________________ >> dancer-users mailing list >> [email protected] >> http://lists.preshweb.co.uk/mailman/listinfo/dancer-users >> >>
_______________________________________________ dancer-users mailing list [email protected] http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
