The method of checking progress on a separate URL similar to the
example I sent does result in repeated requests during upload. But,
they're trivial by comparison - easily in the 100's of req/sec range
of response time and throughput. A bit goofy, but over a single keep-
alive socket for upload operations (likely rare relative to download,
e.g. what you'd expect at YouTube) probably ok
Jim
Sent from a phone
On Jan 19, 2010, at 4:16 PM, Tom Jackson <[email protected]> wrote:
This method could also have the advantage of recovery in case of a
failed upload. A client would look much like a udp application which
tracks packets at the application level.
Once the server side API is set, the client could be javascript, java,
flash or tcl.
The client-side solution also has the advantage of being tailored to
the website, and you could use more bandwidth-efficient compression
and/or binary transfer instead of encoded transfer.
But if you want to provide upload progress to your customers, it seems
counterproductive to create a client which queries the progress via a
separate url. That just greatly multiplies the number of requests the
server must handle.
tom jackson
On Mon, Jan 18, 2010 at 2:39 AM, John Buckman <[email protected]>
wrote:
On 11/24/09 5:13 PM, John Buckman wrote:
Is there any access (in C or Tcl) to an upload-in-progress in
aolserver?
It'd be nice if we extended ns_info with [ns_info driver ...] that
could
give you connection-level info. from the driver thread. In its
simplest
form, all we need is to expose the total bytes read/written on a
socket
from the driver thread. Bytes read of the POST request's body and
the
anticipated Content-Length enables us to compute a rough
"progress" -
using the unique URL bit gives us an opaque handle to identify which
connection we're interested in.
I've learned a few things by deploying a large-file-upload feature
on aolserver:
1) IE times out on large file uploads over DSL, as does Chrome and
Safari. Only Firefox seems to have a long enough timeout to enable
600mb file uploads over DSL.
2) All the other file upload sites use a client-side widget to
upload a file in parts, not using the browser's upload feature at
all. Then, they have a thin server-side program which accepts
small chunks of the file upload at a time. Once the widget decides
the entire file has been sent, it submits to a new web page, which
then collects all the small file chunks.
So... instead of working on an upload-in-progress feature, it would
make sense instead to have a client-side widget (javascript/flash/
java) that sends file upload chunks to a server-side tcl script,
and then have a "harvester" tcl script once the widget says the
file upload is complete.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[email protected]
> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<[email protected]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
