munki

seen as how the thread is solved and mine falls under same category, i'll hijack it :whistling: i'm getting an error "stlport_static.5.1.lib" can't be found. i'm right in thinking it requires stlport to be required? im using 5.1.0 uncompiled and have compiled 0.2.2 fine in the past. any ideas?

public is one you don't supply a password to enter. private isn't really private, it is just one you have a registered account in that isn't a keyed operator. O:x is the point at which the client opens another slot if you upload falls below x. so if O:20 and your upload drops below 2 while all slots are full, another one is opened.

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.

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.

most hubs have $userip now, this sends you their IP address which can be viewed in the IP column of the client. operators are usually set to get the IP address, non-ops arent. this is a hub thing, cant change that. you can however, modify the source to show the IP address in the transfer view, allow copy IP, show IP when you check a user using the client detector thingy. isOP() or somethign to that effect will be in an if statement.

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.

given that DC now uses CIDs to identify users, grouping by CID would work.

$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