What do one have to do...

[bugmenot 0]

...to have you (devs) enable so the maximum dowload slots per file can be raised to above 10?

Please excuse if you have heard this request many times before. I am not here to complain nor nag about it. I was rather thinking about having a rational discussion about it. I hope you will have patience and at least listen and consider.

First of all, I myself agree that it is not good to set this to higher number becouse of the way the network works. However I think that it must be a way to comprimise this....some middle road... some solution to this...

I for example am suffering (in lack of better word) from this. I have a 100/100mbit line and I am only using DC++ (including its mods) for the speeds sake. Nowhere else can i max out my line so easily (when searching for popular content).

The 10 max setting is obviously ruining this, as 10 segments is way to little to even think about maxing such a connection, thus reducing my effectivity (in turn making me take slots for unecseceary long times).

The "disconnect slow downloads" helps to a degree but it is in no way optimal.

I realize that not much % on DC network have this kind of connection, but some (and quite many too) have.

I was thinking that how about you guys do something along the lines of what revconnect did... (but more controlled and better)

What i mean with that is that revconnect measures the speed you are downloading at (per file) and then (per file) shrinks and enlarges piece sizes dynamicly acording to this in a very extreme manner. In theory, this is a good idea, making it so that the slow transfers have less pieces and hence less downloading sources at same time, whilst the fast transfers have more, and the extremely fast ones has much more (but striving to have just enough).

This is done by having an unlimited number of max segments, but piece sizes ranging from extremely small (16kb i think, this really solves the problem where slow sources are stuck at the end of the file) and up to several hundred MBs per piece.

this works in revconnect and it shows however its still to wasty with the slots... especially since it opens up way to many before deciding whos fast and whos not.

I was thinking you guys maybe could set a limit at first to 10 or something and then increase/decrease slowly dynamicly acourding to how the transfer turns out. This will effectively read the quality of the sources the user is downloading from as well as the users connection without asking him for it.

Anyway thats just a thought. Not a request. (hence this part of the forum) I hope we can have a discussion.

Also, I shall register myself normally next time i read here. I am in extreme hurry right now. Sorry if it offends anyone that i logged in like this.

thanks for your time reading this whole thing :(

[Satan 1]

Right, I will take each point in turn here.

I for example am suffering (in lack of better word) from this. I have a 100/100mbit line and I am only using DC++ (including its mods) for the speeds sake. Nowhere else can i max out my line so easily (when searching for popular content).

You are not 'suffering' from this feature, you have simply missed the point of the DC network. DC was not, as you put it, there to facilitate user's maxing there line's. DC is a community, it is not like torrent where it is there simply to allow users to download hundred's of files. You can chat, queue up hundred's of files, and most importantly SHARE.

Hence the reason DC has a share limit for users, it encourages users to share, not like torrent, or limeware etc where everyone leech's and does not give back (sure, torrent 'reward's' sharing, but it does not have hard coding in it to avoid leeching). DC give's the hub owner's the choice (and 99% of them oblige) to inform users they must share x amount to join the hub.

The 10 max setting is obviously ruining this, as 10 segments is way to little to even think about maxing such a connection, thus reducing my effectivity (in turn making me take slots for unecseceary long times).

The "disconnect slow downloads" helps to a degree but it is in no way optimal.

I realize that not much % on DC network have this kind of connection, but some (and quite many too) have.

Technically, it's more than enough, DC++ up until very recently, allowed 1 slot per file, period.

However, this does not mean Apex cannot make good use of your connection. The DC network as I previously said it geared to allow users to queue up multiple files, so if you have 15 files running with 10 slots, this is 150 slots in total. Surely you can easily max out your connection on that?

I'm assuming, if you can't you are not downloading popular files as you previously stated.

I was thinking that how about you guys do something along the lines of what revconnect did... (but more controlled and better)

What i mean with that is that revconnect measures the speed you are downloading at (per file) and then (per file) shrinks and enlarges piece sizes dynamicly acording to this in a very extreme manner. In theory, this is a good idea, making it so that the slow transfers have less pieces and hence less downloading sources at same time, whilst the fast transfers have more, and the extremely fast ones has much more (but striving to have just enough).

This is done by having an unlimited number of max segments, but piece sizes ranging from extremely small (16kb i think, this really solves the problem where slow sources are stuck at the end of the file) and up to several hundred MBs per piece.

this works in revconnect and it shows however its still to wasty with the slots... especially since it opens up way to many before deciding whos fast and whos not.

Out code is already optimised to do this, not quite in the way you say, but it does it without swamping the network like RevC.

It already adjusts segment size in accordance with the uploader's speed. It also disconnects slow users as your slot's fill up with fast users. If you are downloading popular file's this should work even better. You should in essence end up with 10 sources uploading to you in excess of 100Kb/s each! If you use hub's designed for your connection, even faster.

If this is not the case, this is a code error, i.e. a bug, rather than a feature you need implemented.

I was thinking you guys maybe could set a limit at first to 10 or something and then increase/decrease slowly dynamicly acourding to how the transfer turns out. This will effectively read the quality of the sources the user is downloading from as well as the users connection without asking him for it.

We have previously explored using 15 slots on DC and for good reason removed this feature, so to incoorporate such a feature as this would mean we are going backwards.

Also, I shall register myself normally next time i read here. I am in extreme hurry right now. Sorry if it offends anyone that i logged in like this.

AFAIK Lee/Crise do not frown on bugmenot account's (altho I am unsure they know what they are) so that shouldn't be a problem.

thanks for your time reading this whole thing

My Pleasure, was nice to have a detailed thread to answer for once.

[Crise 26]

AFAIK Lee/Crise do not frown on bugmenot account's (altho I am unsure they know what they are) so that shouldn't be a problem.

We are in no way against bugmenot accounts, and yes Satan both of us know what they are Although at certain times we may disable bugmenot accounts temporarily (like during the recent opening of some private forum areas to registered users as a special event), but generally we are in no way against them as long as no problems come from them...

About the subject of the topic, as Satan stated we did try with 15 long ago and the results were very clear... and also as pointed out until very recently DC++, which can nowadays be considered as the mainstream client for DC, allowed no multisource downloading at all. Even though mods have had different implementations of multisource downloading (some better some worse) for a long time now the main reason why it wasn't common is because many hub owners considered, and many still do, multisource downloading as bad news. This is the case probably because DC has long been and still mainly is first to come first to serve based network eg. no real queuing really exists so if user took more than one slot per file for himself this was considered bad.

The 10 segments limit was the original reason why multisourcing got accepted in some hubs to begin with as it was considered good enough compromise between limitless slot hogging and DC++'s single source downloading. Though from what I have heard is that one reason for some hubs to allow clients like SDC and Apex is the fact that they really want to get rid of users that use the old reverseconnect as well as emulating users.

[bugmenot 0]

You are not 'suffering' from this feature, you have simply missed the point of the DC network. DC was not, as you put it, there to facilitate user's maxing there line's. DC is a community, it is not like torrent where it is there simply to allow users to download hundred's of files. You can chat, queue up hundred's of files, and most importantly SHARE.

Hence the reason DC has a share limit for users, it encourages users to share, not like torrent, or limeware etc where everyone leech's and does not give back (sure, torrent 'reward's' sharing, but it does not have hard coding in it to avoid leeching). DC give's the hub owner's the choice (and 99% of them oblige) to inform users they must share x amount to join the hub.

I see your point - but i think its in the eye of the beholder.

I mean, some peoples only use DC for the community... and some use it only for downloading (this is logicly the largest group). And some combine them both. I, myself, started out as the casual downloader getting pissed of at all the bot messages thrown at me (I think we all have been there). I then became a combiner until finally a "community only". However, i grew older and nowadays i dont have the time with such things and therefore i use DC for casual downloading again.

My point: As it is (also) a place for casual downloading among the other things, it should (also) be optimized as such.

Your thought is correct however; The network was never designed for speed. But its users have always wanted it.

This is proven by the fact that (as you know, highly illegal at the time) multisource clients was made.

This transition, i believe, is the reason to why the DC network can produce the highest download rates among the p2p networks.

It started single source and went out with really strong force that no upload limit what so ever was to be used (to optimize the single peer downloading a little)

This way of thinking is obsolete now with multisource downloading, but is still (a bit oddly) enforced by many in the network. This makes it so that each source is (or should be) limit free (this is a rule not found in any other multisource p2p network) thus producing very high speeds most of the times.

Technically, it's more than enough

I disagree. Your way is a very genral way of putting it. It can never be put that way when all users want different things.

It may be enough to some, and not to some others. Difference lies in the line speed of the user and what he is after on the network. Be it just downloading or the community.

DC++ up until very recently, allowed 1 slot per file, period.

Indeed it did. But the change to multisource by official client was forced becouse of the overly unfair advantage multisource clients had in the network. This is proof that the network can change for the better with our (your) changes in the clients.

Becouse of this, new features should be encouraged.

However, this does not mean Apex cannot make good use of your connection. The DC network as I previously said it geared to allow users to queue up multiple files, so if you have 15 files running with 10 slots, this is 150 slots in total. Surely you can easily max out your connection on that?

I'm assuming, if you can't you are not downloading popular files as you previously stated.

You are right. That would be much much more than enough. Actually, to not damage the network i limit the total download numbers to alot less (I will still reach 100mbit on normal ocasions, or ~10MB/s if you will call it that)

The problem lies with downloading just 1 file. Maybe becouse its a very large file or becouse you just want this particular thing and nothing else for the moment.

Just for clarification - I do not nececearaly wish you guys to change the behavoiur of downloading one file at the time. Becouse actually both ways are faulty; if putting much stuff in queue it will result (for most of the users including the very fast ones) in your client taking way to much slots than it needs too, to max your line out. And of course the contrast - when downloading only one file, there is no insurrance that the 10 segments will be sufficient.

The obvious theoreticly solution to this would be to not at all set a limit per file, but instead set a total limit that is dynamic (not user changable, and somehow determines how many segements are needed, totally, at that very moment. Be it with one file or 50 simultaneous downloading files)

Out code is already optimised to do this, not quite in the way you say, but it does it without swamping the network like RevC.

It already adjusts segment size in accordance with the uploader's speed. It also disconnects slow users as your slot's fill up with fast users. If you are downloading popular file's this should work even better. You should in essence end up with 10 sources uploading to you in excess of 100Kb/s each! If you use hub's designed for your connection, even faster.

Well theese are pretty advanced functions and it shows that the client obviously does some measuring about the speeds.

So why not improving the downloading slots mechanism but having it set segements automaticly? Maybe by using similar techniques to how it automaticly figures out which user to assign bigger segment sizes too?

We have previously explored using 15 slots on DC and for good reason removed this feature, so to incoorporate such a feature as this would mean we are going backwards.

I dont know if you misunderstood me. I didnt mean that you guys change the limit itself dynamicly with each release. I meant that the client will do that automaticlly

I have no doubt you see the advantage of this: newbs that cant set their limits correctly which will harm the network in the end would be gone. And peoples with high speed lines that complains that a single file download with 10 segments isnt going to suffice will be happy. (in turn, all clients on the entire network would gain more free slots becouse the peoples that dont need 10 segments, wont - whilst the higher speed users will take more slots than 10 to complete the file but will release them again much faster becouse of the file completing much faster)

My Pleasure, was nice to have a detailed thread to answer for once.

Well, if you do find the time to answer me once more, i hope you dont find it too long to read this time lol.

What can I say...im at work so i have an excuse for typing "in depth"... this is really making the time fly!

Anyway thanks for listening guys im glad you can take a conversation about this. I dont expect it but why not try for changes.

back to work... *sigh*

[Big Muscle 1]

Too much reading for me. So shortly... there's no reason to raise maximum segments above 10 DOT

[bugmenot 0]

Too much reading for me. So shortly... there's no reason to raise maximum segments above 10 DOT

Weird and a little bit funny. A developer of such a an application with no innovation thoughts whatsoever? :(

[Satan 1]

I see your point - but i think its in the eye of the beholder.

I mean, some peoples only use DC for the community... and some use it only for downloading (this is logicly the largest group). And some combine them both. I, myself, started out as the casual downloader getting pissed of at all the bot messages thrown at me (I think we all have been there). I then became a combiner until finally a "community only". However, i grew older and nowadays i dont have the time with such things and therefore i use DC for casual downloading again.

My point: As it is (also) a place for casual downloading among the other things, it should (also) be optimized as such.

Your thought is correct however; The network was never designed for speed. But its users have always wanted it.

This is proven by the fact that (as you know, highly illegal at the time) multisource clients was made.

I see your point, and it is valid, however, unless we put some sort of limit on the number of slot's it will swamp the network.

You have to realise, DC is not like torrent/limewire/ed2k etc with million's of users for every user (centralised if you like). In most cases the most users you will find in a particular hub is 10000 and taking into the consideration the average number of hubs a user is in in 5, that is 50000 users.

Now if all of those user's are using more and more slot's for each file it stand's to reason slot's will run out. We MUST set a limit to avoid this. 10 is a nice round number and as such, I agree whole-heartedly with it.

You also should realise, most user's use DC for rare files (the aforementioned client's are more geared for new 'popular' files). I, myself, use DC for rare files (mostly) and as it stand's rarely have 10 active segments.

If you want, new files, one at a time, fast, don't use DC for them.

This transition, i believe, is the reason to why the DC network can produce the highest download rates among the p2p networks.

It started single source and went out with really strong force that no upload limit what so ever was to be used (to optimize the single peer downloading a little)

This way of thinking is obsolete now with multisource downloading, but is still (a bit oddly) enforced by many in the network. This makes it so that each source is (or should be) limit free (this is a rule not found in any other multisource p2p network) thus producing very high speeds most of the times.

I can't agree with this, DC is NOT the fastest network, not by a long shot. Get yourself a demonoid account and use torrent, you will see what speed really is.

I disagree. Your way is a very genral way of putting it. It can never be put that way when all users want different things.

It may be enough to some, and not to some others. Difference lies in the line speed of the user and what he is after on the network. Be it just downloading or the community.

The intention with DC is not to 'please everyone'. It fulfil's the purpose for which it was original intended. That is, for user's to connect to each other, therefore increasing file base, in a way, MS downloading attracted the speed-a-holic users. But going back to the 'spirit of DC' once more this was never the original intention. But with innovation, come's problem's. This is just a sideline to MS downloading, but MS downloading also brought many positive's, hence why it has survived thus far.

Indeed it did. But the change to multisource by official client was forced becouse of the overly unfair advantage multisource clients had in the network. This is proof that the network can change for the better with our (your) changes in the clients.

Becouse of this, new features should be encouraged.

Incorrect, the move the MS by DC++ was ALWAYS intended as part of ADC implementation, unfair advantage had nothing to do with it. If it did, it would of arrived MUCH sooner, i.e. MS downloading has been around in DC for years.

You are right. That would be much much more than enough. Actually, to not damage the network i limit the total download numbers to alot less (I will still reach 100mbit on normal ocasions, or ~10MB/s if you will call it that)

The problem lies with downloading just 1 file. Maybe becouse its a very large file or becouse you just want this particular thing and nothing else for the moment.

In that case, what is your hurry? Why not leave DC running overnight, you come back next day, and it's all finished

I cannot see a case where this would not work.

Just for clarification - I do not nececearaly wish you guys to change the behavoiur of downloading one file at the time. Becouse actually both ways are faulty; if putting much stuff in queue it will result (for most of the users including the very fast ones) in your client taking way to much slots than it needs too, to max your line out. And of course the contrast - when downloading only one file, there is no insurrance that the 10 segments will be sufficient.

The obvious theoreticly solution to this would be to not at all set a limit per file, but instead set a total limit that is dynamic (not user changable, and somehow determines how many segements are needed, totally, at that very moment. Be it with one file or 50 simultaneous downloading files)

Well theese are pretty advanced functions and it shows that the client obviously does some measuring about the speeds.

So why not improving the downloading slots mechanism but having it set segements automaticly? Maybe by using similar techniques to how it automaticly figures out which user to assign bigger segment sizes too?

There are thing's in place to counteract what you say. For example, you can only use 1 slot from a user per hub. So you can't swamp a user with a large queue.

Also, a large queue will still only allow so many slot's overall. Secondly, using a lot of slot's for one file will be unfair on others. Each file will only have so many sources. So setting an overall limit will lead to one user having the ability to get a slot from every user with that file, meaning other user's wanting that particular file can't have a slot. Whereas with a large queue, different file's give's more chance of different users.

I have no doubt you see the advantage of this: newbs that cant set their limits correctly which will harm the network in the end would be gone. And peoples with high speed lines that complains that a single file download with 10 segments isnt going to suffice will be happy. (in turn, all clients on the entire network would gain more free slots becouse the peoples that dont need 10 segments, wont - whilst the higher speed users will take more slots than 10 to complete the file but will release them again much faster becouse of the file completing much faster)

Most people don't use 10 segments unnecessarily. DC already close's slow slots. So this is pretty much null and void. As I said, at present, I have five simultaneous files at mo, using in the region of 3 slots each.

Well, if you do find the time to answer me once more, i hope you dont find it too long to read this time lol.

What can I say...im at work so i have an excuse for typing "in depth"... this is really making the time fly!

Anyway thanks for listening guys im glad you can take a conversation about this. I dont expect it but why not try for changes.

back to work... *sigh*

I tried to answer this in work, no luck, too busy to answer this. So i've left it till I got home

Weird and a little bit funny. A developer of such a an application with no innovation thoughts whatsoever?

You gotta be honest, it is an extremely long post, (and getting longer), and BM is probably busier than you or I.

[bugmenot 0]

Actually last time i came to this forum (when i typed the text above) i actually thought there was some hope left for this community i realized however that my lentghy posts here means nothing.

This project and community is dead and its almost singlehandedly becouse of the devs here. Lets face it. ApexDC++ is nothing more than a StrongDC clone. They cant even add feautures themselves but must wait for upcoming strong version. When asked what difference there really is, other than skin, you get no response (or a ridiculus answer stating new feautures that makes you think its little childs doing this mod). This is no mod peoples, It's like StrongDC with smiley packs.... And StrongDC by itself has been a dead project since a very long time ago, when the developer lost all grip of what spirit lies in filesharing, and the community as a whole. Given that he also seems to run the place around here only makes it worse.

This is a shame indeed but until someone steps up and changes things around with some other mod, that maybe get a community going, its not going to change.

To Apex devs: you really digged your graves on this one... i wish you should look around the forums (espacially future requests section) and see what this place actually became. And learn from it. I had MUCH higher hopes for this mod when it emerged so long ago.

Well thats it for me funny coming back here after all this time tho

oh and...

You gotta be honest, it is an extremely long post, (and getting longer), and BM is probably busier than you or I.

I seriously doubt that my friend id be extremely surprised if he wasnt a very lonely person...

[Guest Toast]

Well i do have to admit that its been kinda deadish here but Crise said it would be after this rls since he wanted a break but i guess u didn't read the announcement or the rls notes.

As for being a sdc clone well its kinda hard not to be a clone since its based of that client but apex has some differences from strong.

you had 2 developers answer you in this post whatever they said should have been good enough i didnt read the post cause your attitude kinda rubs me the wrong way.

[Crise 26]

I don't know if you'll read this, but going to post anyways, for starters you seem to have a very interesting concept about what is and isn't a dead project.

You say StrongDC is dead since long time ago, but you don't seem to be quite up to date with the situation, StrongDC is far from dead you see. Last I checked BM released a brand new version not so long ago (about three weeks actually), with a lot of nice fixes and changes in it too.

You also say ApexDC is dead, which is also incorrect, last release was made on 24th of December last year and that's not so long ago considering that I am not getting any more free time out of anywhere.

Now about the rest of your, lovely, feedback. You say that "ApexDC is nothing more than a StrongDC clone", that's your first and only correct remark. Since in the end without (S)DC++ ApexDC would nor could ever even have existed to begin with. It might be but a mod of a mod but it's our mod and no-one else's.

You also said that when asked what is different between StrongDC and Apex the answer given is ridiculous, or features stated are of the sort that make you think that children are behind this project. True the differences might not seem significant to you but to me most of the represent a learning experience or a challenge I have had to face in the past.

Now little something regarding that child remark of yours, because you are actually not that far off, had you made that same comment few years back the answer would have been yes. Because when ApexDC began in early 2006 I had just barely turned 16 (having had my first touch with real programming little over a year earlier when all this craziness originally began).

Also, just for the record. I read almost every single post that gets posted on these forums, not so constructive feedback and feature requests alike, and will continue to do so in the future. But if I were to reply to every single one of them the content of those replies would be not only unacceptably low in quality but also most likely rude towards the original poster. It's also a matter of preservation of motivation in some cases, because there is limit to everything and f.ex. I have made a decision not to handle that many support requests personally anymore (dunno if some have noticed) because dealing with them can get very repetitive over time.

Also just to clear things up, I respect BM as a senior developer and also because his skill and knowledge of (A)DC protocol and the DC++ code base still certainly surpass my own. But BM does not run things here, as you are implying above, although we do share a common view in some matters (like the matter originally discussed in this topic, for instance).