segments

[munki 0]

i don't know if this is on the roadmap, but it would be nice to have a list of files that are exempt from segmenting. rather annoying when an apexdc user connects to my share client (CZDC) and progresses through files in 1mb increments. supreme waste of bandwidth also.

if there is a list of files to be exempt from segments, would be good to set a minimum size for each, if the file is more than that, then it can segment. only thing i have found is more of a global setting on manual number of segments. really like this client, hoping more people use it in our hub.

[Goralf 0]

A n00b question perhaps, but how does the 1MB increment download waste bandwidth?

[Zlobomir 3]

Maybe only by some bits for verifying of each segment...

[munki 0]

$ADCGET file TTH/QHQDWX4QQCD2NKEMOXB7FC44RVSCXZ3Q45OQESY 27262976 1048576 ZL1|

$ADCSND file TTH/QHQDWX4QQCD2NKEMOXB7FC44RVSCXZ3Q45OQESY 27262976 1048576 ZL1|

that occurs for each segment. a 47.68mb file does this 47/48 times per file times it by 95? about 4500 times as opposed to 95. 80bytes per line, twice for each segment.

95 = 14.84kb

4500 = 703.13kb

and that is just protocol data, no binary transfer. give or take, because, obviously, the start and finish segments change.

that's by the by, it is just very annoying to see. i'm sure this is not the desired effect of multisource downloads

[poy 0]

this is the old way RevConnect used to download in multisource, and now the code has changed and it's much more efficient in this way: only one big $ADCGET is sent; not one for each chunk; and if 2 chunks have to overlap, let them overlap...

since StrongDC++ 2 implements this new RevConnect code, and ApexDC++ too, i guess you will find less and less of these people who use clients based on the old RevConnect multisource code. anyway, if it's too much annoying to you, you can always block them by using CZDC (this could be added to ApexDC++ too )

[Big Muscle 1]

Revconnect always sent one $ADCGET which causes losing a slot at the end of chunk.

2munki: where did you get thess numbers? they are absolutely false.. what is 4500x ?

$ADCGET will be sent 48 times per file for 47.68mb and if one $ADCGET command has 80 bytes, it wastes only 3,8 kB (8 kB counting also $ADCSND) and it's much better than losing a slot after segment and waiting a few days for slot from someone and then lose it again.

and CZDC is being banned in a lot of hubs if someone enables to block segmented uploads.

[poy 0]

Revconnect always sent one $ADCGET

ok, thanks i didn't know that. actually, i've seen some clients like Zion++ behave like this (a lot of $ADCGET sent) and i thought they took the code from an old RevConnect...

which causes losing a slot at the end of chunk.

i quickly tested the multisource with RevConnect and from what i've seen, it sends a big $ADCGET just like the vanilla DC++ would do; eg GET file XX 0 9999 for a file that would be of 9999 bytes. so i don't see how it could loose its slot, it should just download the file up to the end?

and if 2 downloads are downloading the same chunks, it didn't (in my quick test) close/re-open any of these downloads; it just downloaded both chunks simultaneously so that it didn't loose any slot. (it's what he calls "overlapping" in the source)

but please correct me, i guess you've understood this much better than me... :P

[Big Muscle 1]

when one chunk claps on another chunk, the download must be disconnected and reconnected to download another chunk from that user. And when it disconnects, another user can "steal" your slot

btw clients like Valknut are much worse, because they send new $ADCGET every "TTH-leaves size" (usually every 64kB)

[Goralf 0]

It is very interesting to know how it actually works.

Thanks a lot Big Muscle for the explanation.

Keep your excellent client versions coming. :)

[poy 0]

indeed, thanks :)

[munki 0]

numbers were based upon a 95 file test, each being 50000000 bytes. i have seen this from mroe than one user, all of which were using 0.2.2 apexdc. 1 mb segments. i haven't bothered to check this out since i tested last time but 1mb segment on a 47.68mb file sends adcget 48 times, and for the 95 files, that works out to 4560. yes i know segments will cause more bandwidth to be used, but this is extreme and, i am sure, not the desired behaviour.

[Big Muscle 1]

ok, it wastes about 800kB for 95 files but you wouldn't be able to download 95 files so fast with normal method because you lose your slot in short time.

And it has already been said that multisource downloading is designed for fast connections only so there's no reason to complain that it downloads about 800kB more per 95 files.

[munki 0]

as i said in my first post. this isn't why i was bringing it up. it was to do with the 1megabyte segments. can forget the wasted protocol bandwidth, was just an observation. other multisource clients have more control over how small segments are and are able to define a list of extensions which do not multisource. this is an issue for any connection, not just the targeted faster ones.