[ADC-Ext 1.0.8] Downloaded progress report for Uploaders

Locked
Crise
Senior Member
Posts: 139
Joined: 10 Nov 2007, 21:34

[ADC-Ext 1.0.8] Downloaded progress report for Uploaders

Post by Crise » 10 Aug 2013, 17:32

When file segments are not downloaded sequentially, the info in current ADC GET command does not permit displaying relative upload progress for the uploading party (for the whole file).

To address this we (ApexDC) added an optional named field to GET command "DB" for current downloaded (and verified) bytes before the current request. While still not entirely accurate with this information the uploader can see how much of the file the requesting party actually has instead of either assuming that the requester has the file upto the start position of the request or being forced to only show the progress of the currently requested part of the file. There is a slight delay in the reporting of this info in scenarios where more than one segment of a file is simultaneously requested (by the downloader) and the uploader still lacks information about how many other sources the file is being downloaded from.

Crise
Senior Member
Posts: 139
Joined: 10 Nov 2007, 21:34

Re: Downloaded progress report for Uploaders (GET)

Post by Crise » 25 Sep 2013, 09:18

There is now an implementation of this in public distribution, that is if you can call it by that name... considering how trivial it is.

This seems to have bled through to NMDC ADCGET as well, but to be frank I don't see any problem with that after all ADCGET is still technically just an ADC command in NMDC context.

Pretorian
Site Admin
Posts: 214
Joined: 21 Jul 2009, 10:21

Re: Downloaded progress report for Uploaders (GET)

Post by Pretorian » 06 Oct 2013, 13:50

This is the (minor) discussion regarding this extension
[2013-08-11 19:17:44] <Pretorian> Crise: Have you added the downloading field to the GET or will you?
[2013-08-11 19:18:18] <Pretorian> I don't see a direct problem with it, and if you have already implemented it, then the extension should be in ADC-Ext.
[2013-08-11 19:28:26] <Crise> my version has it, the current release version doens't
[2013-08-11 19:28:38] <Crise> * doesn't
[2013-08-11 19:30:17] <Crise> it is worth to also note that even if a client itself doesn't request chunks out of sequence it can have chunks requested from it in this manner, so sending the field even if it is not parsed would be helpful to other clients
[2013-08-11 20:00:56] <Pretorian> One could argue about waste of resources (bandwidth) but I don't see that as a problem in (primarily) C-C.
[2013-08-11 20:54:04] <Crise> Pretorian: I would counter that by claiming that having more accurate info about file progress the uploader is less inclined to go offline if an upload looks like it is going to finish soon (of course only applicable to someone who isn't a total leech)
[2013-08-11 21:19:13] <Pretorian> Crise: Yeah, I know. It's the only real opposition I can easily come up with.
As there has no been any objection to the extension and there's an implementation, I'm proposing the following text:
=== Downloaded progress report for uploaders in GET
When file segments are not downloaded sequentially, the info in the current GET command does not permit displaying relative upload progress for the uploading party (for the whole file).

To address this, this extension will add an additional field to the GET command for current downloaded (and verified) bytes before the request has been sent. While still not entirely accurate with this information, the uploader can see how much of the file the requesting party actually has instead of either assuming that the requester has the file up to the start position of the request or being forced to only show the progress of the currently requested part of the file. There is potentially a slight delay in the reporting of this info in scenarios where more than one segment of a file is simultaneously requested (by the downloader) and the uploader still lacks information about how many other sources the file is being downloaded from.
[options="autowidth"]
|=====
|DB |Downloaded (and verified) bytes.
|=====
Edit: "before the current request" -> "before the request has been sent"

poy
Member
Posts: 78
Joined: 26 Nov 2008, 17:04

Re: Downloaded progress report for Uploaders (GET)

Post by poy » 07 Oct 2013, 18:56

That seems very useful; one nit:
Pretorian wrote:
When file segments are not downloaded sequentially, the info in the current GET command does not permit displaying relative upload progress for the uploading party (for the whole file).
The same issue affects sequential segments as well, as the uploader can't know whether the downloader is already downloading other segments in parallel. I would remove "When ... sequentially".

Crise
Senior Member
Posts: 139
Joined: 10 Nov 2007, 21:34

Re: Downloaded progress report for Uploaders (GET)

Post by Crise » 19 Oct 2013, 16:57

poy wrote:That seems very useful; one nit:
Pretorian wrote:
When file segments are not downloaded sequentially, the info in the current GET command does not permit displaying relative upload progress for the uploading party (for the whole file).
The same issue affects sequential segments as well, as the uploader can't know whether the downloader is already downloading other segments in parallel. I would remove "When ... sequentially".
Most sequential (read: older) clients do not download segments in parallel which is probably what was going through my head when I wrote that sentence (not objective like any text in a specification should be, but I wasn't expecting it to be quoted), but I agree the issue is universal.

Also, "... displaying relative upload progress for the uploading party" -> "... displaying relative upload progress by the uploading party" as for would imply the downloader is doing the displaying of the progress, but all he is doing is providing the information to do so. It might also be worthwhile to change all instances of the word party to peer or client, whichever is the preferred word by the specification.

Though I would argue that all clients should thrive to download segments in a "smarter than linear order" but that is a different discussion for a different day and extension entirely.

Locked