Auto grant slots for whole hub (distro-hub)

[TVS]Dulf · Post by **[TVS]Dulf** » 2004-02-09 16:00

I run a distribution hub for a DC hub network, its meant for fast distribution of new episodes of TV series.

What I would like to be able to do is automaticaly grant an extra slot to every user in that hub, for solong as they are there.

Kinda like putting all users that enter that hub in your favorite users and auto granting them, and keeping track of who leaves, and revoking their autoslots......
only with less handywork...

should be easy enough, and i can see no obvious drawbacks..

any thoughts?

Post by **GargoyleMT** » 2004-02-14 18:35

And presumably you cannot set your slots to a rediculous number because you're on other hubs and don't want those users to get all your slots?

[TVS]Dulf · Post by **[TVS]Dulf** » 2004-02-19 16:12

Well, no..
I dont have unlimited bandwidth...

the point is to first get the new episodes out there as quickly as possible, that means giving high BW members that are known to share stuff as soon as they get it an extra advantage over people in other hubs, about who you dont know if they'll share, or just leech, at least as long as there are only a few (say less then 10) ppl that share that particular episode.

I fail to see how this is a bad idea...

ivulfusbar · Post by **ivulfusbar** » 2004-02-20 05:35

This issue is also related to the "its not currently possible to use different shares in different hubs". Please read those threads which will explain that its not possible without some ugly changes in ports-listening and others.

this-can-be-fixed-when-we-have-the-magic-cookie.

[TVS]Dulf · Post by **[TVS]Dulf** » 2004-02-21 05:49

I disagree.

I dont really care about what i share where, anybody can get the stuff I share.
Its about giving extra slots to some people, a feature already present in DC++, only I want to do it for an entire hub automaticly, instead of some users manually.

Post by **GargoyleMT** » 2004-02-21 12:30

[TVS]Dulf wrote:I want to do it for an entire hub automaticly, instead of some users manually.

[TVS]Dulf wrote:that means giving high BW members that are known to share stuff as soon as they get it an extra advantage over people in other hubs

I'm confused. These two statements only make sense if the hub you're in is small and full of couriers only.

fusbar's comments do make sense given that for your feature to grant someone a slot, you have to know which hub they're on - that's the primary difficulty for per-hub shares.

ivulfusbar · Post by **ivulfusbar** » 2004-02-21 18:32

Again, the issue is that you can't identify which hub a user comes from in a user<->user connection. Thats the point.

if-you-would-have-read-the-threads-i-pointed-you-to-instead-of-disagreing-then-you-might-have-understood-ly'ers. ,))

Todi · Post by **Todi** » 2004-02-22 05:53

ivulfusbar wrote:Again, the issue is that you can't identify which hub a user comes from in a user<->user connection. Thats the point.

I'm probably missing something here, but wouldn't the $ConnectToMe / $RevConnectToMe provide a clue?

ivulfusbar · Post by **ivulfusbar** » 2004-02-22 10:55

Yes you are... look in the others threads.. it described in several of them. ;))

Todi · Post by **Todi** » 2004-02-22 11:48

Fusbar, please give me some credit.

I've gone over about 30 threads about this, some almost a year old. But the only thing i've found really is a (possible) problem with DC++ not being able to keep the hubs apart because they run on the same port. I have honestly not been able to find a protocol reason for this not to work, as long as DC++ can identify the hub sending the data by it's IP, which should be possible (but perhaps requires too much work? I cannot tell since i'm not familiar with the code).

In your infinite wisdom, perhaps you could point me to the thread which explains this in stupid speak, that i keep missing. Thanks.

ivulfusbar · Post by **ivulfusbar** » 2004-02-22 12:44

Todi: it was not ment to be sarcasm or any forum-howto behave kind of reply.. i can try to guide you in the subject if you are interested.

As you can see in my reply above, it would require dc++ todo some ugly changes in port-listening. I.E. we would have to have one listening socket / share-profile or AutoGrant-profile. This is a solution that has been rejected by most developers so far (configuring ports is one of the most commen problems users have, and having to set several would be to much for them.)

In the client-client protocol.. no information other than "nickname" is used to identify connections. This means that if you have two different users on two different hubs, you might get into trouble.. As you can not easily figure out who of them is connecting to you. Ofcourse you can try to keep a record of somethings and refuse to expect connections from such users at the same time... But this is not a valid solution either (atleast not to me).

You can ask yourself why no identification was done in client-client, well from the beginning the DC-protcol was never ment to be used in a multihub envoriment. And therefor no identification was needed.. Then later on some extension in the protocol was made to enable searching and connection to other users in hubs through the hub.. but still no changes was made in the client-client protocol.

Than you have the issue with passive/active users which makes it more complicated..

In ADC, we will have a magic cookie that can be used to identify users in the client-client level. I.E. to get a feasible solution we had to make some simple changes.

Todi · Post by **Todi** » 2004-02-23 10:02

Thanks for the explanation fusbar =)

I was under the impression this could be done by keeping track of the hub sending the ConnectToMe somehow, but i guess it's better to wait for something like ADC.

Perhaps some users would still find it acceptable to grant slots to every nickname on the userlist of that particular hub, even if it would mean you might be granting slots to similary named users on other hubs as well.

ivulfusbar · Post by **ivulfusbar** » 2004-02-23 10:05

xayide wrote a more detailed explination on how you can try to guess most correct in a post several months back when he was working on his CDM. This would require that you know somewhat how dc++ works.

http://dcplusplus.sourceforge.net/forum ... php?t=4446

Most CDM-devs have experienced issues with running their CDM on different hubs at the same time... This was an comment from him what you can do about it.

Krissam · Post by **Krissam** » 2004-02-24 09:14

1 word, bittorrent

Post by **GargoyleMT** » 2004-02-28 12:52

Krissam wrote:1 word, bittorrent

Bittorrent certainly is a good solution for distributing material. Maybe this is news to the original poster, but... I think he was looking for a way inside the DC network.

[TVS]Dulf · Post by **[TVS]Dulf** » 2004-03-03 15:37

Kinda like putting all users that enter that hub in your favorite users and auto granting them, and keeping track of who leaves, and revoking their autoslots......

can you have like a timer that every 5 minutes checks the userlist of one hub, and does "the thing" that autogrant does for favorite users?

or another trick:

Again, the issue is that you can't identify which hub a user comes from in a user<->user connection. Thats the point

perhaps not, but I dont want to know from what hub somebody connects to me, I want to know if he's in my hub. If any form of identification (nick, ip whatever) is sent during the connection phase, my client could then check to see if the requestor is or is not in my hub, and decide whether or not to grant a slot.

fusbar's comments do make sense given that for your feature to grant someone a slot, you have to know which hub they're on - that's the primary difficulty for per-hub shares.

i dont really care what *other* hubs they're in, as long as they're also in my hub. Also being in other hubs is kinda the point

cologic · Post by **cologic** » 2004-03-03 20:50

I dont want to know from what hub somebody connects to me

I want to know if he's in my hub.

Haha.

[TVS]Dulf · Post by **[TVS]Dulf** » 2004-03-03 21:57

what...

there's a distinct difference.
i dont care from what hub (that we're both in) somebody connects to me; as long as he's currently (also) online in my hub, he gets an extra slot....

how hard can it be?

function bCanIGetASlot (NickName)
if bInHub(MyHub, NickName) OR (bIsFavoriteUser (NickName) AND bAutoGrant (NickName)) OR bIHaveOpenSlots then
bCanIGetASlot = true
else
bCanIGetASlot = false
end if
end function

port to c++ and you're done...

cologic · Post by **cologic** » 2004-03-03 22:04

ivulfusbar wrote:This means that if you have two different users on two different hubs, you might get into trouble.. As you can not easily figure out who of them is connecting to you.

Nick1 is on your hub.
There's a separate Nick1 on another hub.
Should that other Nick1 also get the distribution hub auto-slot?

Qbert · Post by **Qbert** » 2004-03-03 23:24

[TVS]Dulf wrote:as long as he's currently (also) online in my hub, he gets an extra slot....

Why can't you just run a special instance of DC++ for this distribution hub, and set the number of slots to 999? Doing that seems to solve your problem, at least from what I understand it to be. Why try to mess with the code which suddenly becomes related to a huge problem and protocol deficiency.

GargoyleMT wrote:And presumably you cannot set your slots to a rediculous number because you're on other hubs and don't want those users to get all your slots?

GargoyleMT sure did quickly have the easiest idea.

[TVS]Dulf wrote:Well, no..
I dont have unlimited bandwidth...

Make up your mind. You either want to give everybody in this hub a slot or not?

[TVS]Dulf · Post by **[TVS]Dulf** » 2004-03-04 12:23

cologic wrote:
ivulfusbar wrote:This means that if you have two different users on two different hubs, you might get into trouble.. As you can not easily figure out who of them is connecting to you.
Nick1 is on your hub.
There's a separate Nick1 on another hub.
Should that other Nick1 also get the distribution hub auto-slot?

How does DC++ make that distinction when that nick is in your "favorite users"?

all i want is automated favorite user adding and removing, with extra slot granting.....

cologic · Post by **cologic** » 2004-03-04 12:29

It guesses, and I've seen it do so incorrectly many times.

[TVS]Dulf · Post by **[TVS]Dulf** » 2004-04-07 12:12

if that "guessing algorithm" is good enough for granting "Favorite Users" extra slots, then its good enough for granting "All Hub X Users" an extra slot.....

Post by **GargoyleMT** » 2004-04-09 08:34

Actually, it's not. That's what cologic is saying.

Ok, here's a real example: I'm on two hubs that cologic is on. I can add him to my favorite users and auto-grant him, but if he asks for files on the second hub I've seen him in, he will not be auto-granted a slot.

The same thing can happen by triggered by manually granting him a slot as well.