per hub customization

[bigcanuck 0]

So I think it would be a neat idea if would could in our favourites set our upload and download slots differently per hub. As many hubs have min/max slots requirements and it'd be nice to be able to manage them seperately . Implementation wise... I don't think it'll be too hard I'll look at the code I have and see if I can see an in. *not that I can build a patch but I can at least take a look*. Lemme know what you guys think. And as I said this may have been talked about already.

[Zlobomir 3]

Nice idea, but won't it be in conflict with slot number in setting general settings? Or you mean the number in GS to be some top limit, which to be distributed with "per hub" settings?

[bigcanuck 0]

Nice idea, but won't it be in conflict with slot number in setting general settings? Or you mean the number in GS to be some top limit, which to be distributed with "per hub" settings?

Ya sorta.. like the username thing. so...

in favourites::

if field is void, get default settings

otherwise broadcast these settings to hub.

::Edit:: so.. since Apex keeps track of which hub the user is downloading from, you could set it so that Hub A is allowed 4 slots... while hub b might be allowed 1 I think... that works

[Kulmegil 1]

it looks quite easy "on the paper" but I really was going to put similar feature into action. I definitely lack skills from all dc devs unfortunately. But since someone has put out this req. I have this question somehow related to implementing similar thing...

I'm trying to figure how much userconnections are related with hubs. All I know now is that userconnection object has "hubUrl" string.

I also know how DC behave in NMDC environment, but ADC is quite new to me:

I have this user who has an interesting file I want to get (so he's a source).

We are connected together to let's say 3 hubs.

In those are NMDC hubs it will try to make connection on each of them, coz it doesn't recognised that my source is the same user.

But how will DC++ react on ADC? Will it make a connection on each hub?

(if not how can I determine witch hub specific slot should be taken by user?)

[Zlobomir 3]

Hey, in NMDC now I guess that we can with 99% exactness distinguish users by NickIP[Description]ExactShareSize... And even e-mail, etc... It's not very likely all these to be the same, yet if they are it should be one user with 2 clients/instances (who IMHO can be treated as one user)

[bigcanuck 0]

But how will DC++ react on ADC? Will it make a connection on each hub?

(if not how can I determine witch hub specific slot should be taken by user?)

hmm good question. and ya on paper is always a little difference then in practice.

[Squelch 0]

It's a great idea,

Going a little further, are profiles a possibility?

Having 2 or 3 different share trees for different hubs. Some hubs don't like music and films, so having a subset of the default share only for that hub would be nice.

[Zlobomir 3]

It's a great idea,

Going a little further, are profiles a possibility?

Having 2 or 3 different share trees for different hubs. Some hubs don't like music and films, so having a subset of the default share only for that hub would be nice.

This has been discussed, and yes, it may be possible with ADC, but for now it's not very easy to implement.

[Kulmegil 1]

I think it could be done to make DC++ generate different filelists, but I don't know about search responses.

[Squelch 0]

Isn't the "Auto grant extra slot" option for favorite users a partial method of what bigcanuck is asking for? If this could be implemented hub wide on the enabled hub in favorites, wouldn't this achieve what is required regardless of multiple user id's on different hubs?

If a truncated version of the default filelist is presented to a hub, then surely searches would still give the correct resposes to another user. If they are on another hub, and see the other content, then they could only download via your id on that hub. It appears to me, that the same user (even with different nick) on different hubs, is treated as different users even though they have the same content. Therefore changing the filelist presented as that user doesn't matter.

Both of these seem related.

[ifmn 0]

If I remember right, in Stealthy 2 there was and option for 5 different FL and you could select which FL to give to some hub in favs.

[Kulmegil 1]

Well... judging from the fact that "hide share" works perfectly and block responses for hub with hidden share it's also possible to alter search results for this purpose. And for filelist it's just a matter of generating additional one (or more) I think (whenever you generate normal one) with filtered content only. Although I didn't day it's that easy when comes to implementation :x

[Zlobomir 3]

I am more concerned about the disk space these filtered lists will eat up. Will it be like 5xYourNormalList, when having 5 FLs?

[ifmn 0]

I am more concerned about the disk space these filtered lists will eat up. Will it be like 5xYourNormalList, when having 5 FLs?

Yes, but you can disable(actually not use them) them if the HDD space is so precious for you and for some users //like me// the FL is only 50KBs big :thumbsup:

BTW I just checked stealthy 0.251 //or smt like that// and it did have 5 FL and customizable slots for each hub.maybe if you ask Phaedrus he'll give ya the src.

[Zlobomir 3]

Yes, but you can disable(actually not use them) them if the HDD space is so precious for you and for some users //like me// the FL is only 50KBs big

BTW I just checked stealthy 0.251 //or smt like that// and it did have 5 FL and customizable slots for each hub.maybe if you ask Phaedrus he'll give ya the src.

Yes, but to be real, the FL should require a Hashindex/Hashdata? Will 5 FLs be able to use parts and references to the existing Hashindex/Hashdata, or they will require a separate couple for each FL? :thumbsup:

P. S. I am having a problem with the Quote button, left to Reply. Using Firefox 2.0.

[Crise 26]

P. S. I am having a problem with the Quote button, left to Reply. Using Firefox 2.0.

Works fine here :thumbsup:

[bigcanuck 0]

Yes, but to be real, the FL should require a Hashindex/Hashdata? Will 5 FLs be able to use parts and references to the existing Hashindex/Hashdata, or they will require a separate couple for each FL? :thumbsup:

They should be able to use the existing hash index to create an FL, ie the client keeps an overall Hash index and then you omit said index's as per each hubs file list.

P. S. I am having a problem with the Quote button, left to Reply. Using Firefox 2.0.

Quote function also works for me :)

[Squelch 0]

Yes, but to be real, the FL should require a Hashindex/Hashdata? Will 5 FLs be able to use parts and references to the existing Hashindex/Hashdata, or they will require a separate couple for each FL? :thumbsup:

P. S. I am having a problem with the Quote button, left to Reply. Using Firefox 2.0.

I think the hash table is simply that. The file list references the index for that file in the table. I'm not sure if adding files different to the default tree would cause problems, but I'm only after a subset of the default tree so the files have been hashed anyhow.

I had trouble with topic tool button after forum update too. Try a hard page reload (Ctrl-F5)

[Zlobomir 3]

I think the hash table is simply that. The file list references the index for that file in the table. I'm not sure if adding files different to the default tree would cause problems, but I'm only after a subset of the default tree so the files have been hashed anyhow.

I had trouble with topic tool button after forum update too. Try a hard page reload (Ctrl-F5)

This is one and the same, i. e. if you add new files to a smaller share it will become your larger one, and the first "edition" will become a subset. May be more dificult for coding, but there should be some way to do that.

I mean, best case is to have one BIG share with FL for most hubs, and smaller FLs for exceptions. :thumbsup:

[Kulmegil 1]

hashindex / hashdata will keep all files overall. Changing that will rather make more mess then helps.

All You have to altered is:

* what exactly will be generated on FLs

(FL is relatively rather small... but I saw very few users with FL over 10MB)

(I have 1,4TB and FL only takes 450kb - but it's really number of files that metters)

* witch FL is send to users depending on hub, much like Hide Share mod

(I'm not sure if hide share works in ADC correctly)

* last but not least - search responses also depending on hub.

[Zlobomir 3]

@Kulmegil: So how many files you have in these 1.4TB? Even 10MB per FL is acceptable, and for sub-FLs size should be far smaller.

[Kulmegil 1]

To be precise - FL size depends directly on number of files (and average filename size but we can skip that coz it's totaly unpredictable; dir takes up only around 1/3 space compared to file entry). And one more obvious factor is that "old style", uncompessed *.DcLst is larger then new *.bz2.

I could found easily guy with 17,36GB share and 1,8MB FL. I have 11k files total.

PS Size won't will be even less important (in terms of getting them) on ADC where You can grab only important part of FL

[Zlobomir 3]

F:\!AV\My Music\2. Foreign\A\Accept\1979 - Accept

Here is an example for a longer path. I have ~40 000 files, ~140GB, but can't find my FL.

[Kulmegil 1]

FL will be generated in settings directory when needed (use File >> Open own file list to force it's creation). 40K files would generate around 1,5MB FL?

We are really getting offtopic here :D

[bigcanuck 0]

We are really getting offtopic here

meh no worries it's sorta partly on topic anyway, because to be able to generate different filelist/open different slots per hub is sorta all the same problem in a way, if we can do one we should be able to do the other :)