Different Share for different HUBs

[ent0r 0]

yes, it might be difficult to implement, and may not be your liking.

Nonetheless i sugest it, since it is annoying, that i cannot share certain "exotic" files, that are not allowed in i. e. Comic Hubs.

[Zlobomir 3]

As for me, it's very much to my liking, but in a previous topic we ended with the decision that the protocol is still not good enough. Additionally, with a great share, one hashing for each hub looks like a nightmare for me, and probably waste of HDD space. But you can have two instances of the program opened. This reminds me to ask for the options "Allow multiple instances" and "Ask each time" (this is current state), which will save some time.

Edited September 2, 2006 by Zlobomir

[Pothead 0]

I've now heard of a way to do this successfully with NMDC protocol.

You'll need a TCP and UDP port open for each share you have.

Well that will work for active users, for passive users, erh, hmm, need to think about his one some more.

Or only make it available to active users that will pursuade more people to bother trying to become active. :)

[datadyne 0]

That sounds rather difficult to implement. :-\

[Greg 0]

It's far from easy to implement, dispite being possible on the protocol maybe. I'm sure it'd use more resources too? I'd like the feature myself, but I think you'll just have to accept this as a limitation.

[poy 0]

I've now heard of a way to do this successfully with NMDC protocol.

You'll need a TCP and UDP port open for each share you have.

Well that will work for active users, for passive users, erh, hmm, need to think about his one some more.

Or only make it available to active users that will pursuade more people to bother trying to become active. :fear:

i don't understand your point about the need of active and passive and stuff... don't you just have to create different file lists, and choose which one to use for each hub you connect to?

then of course, handle uploads and answers to searches correctly so that you don't answer to one hub's user you have a file while it's not in the list you have choosen for this hub...

[Pothead 0]

i don't understand your point about the need of active and passive and stuff... don't you just have to create different file lists, and choose which one to use for each hub you connect to?

No. With NMDC protocol there is always the user guessing. The only way to actually tell which filelist to send, is for each share to have a specific port. So when they $ConnectToMe nick ip:port| you can tell from the port number they connect with, of which filelist to send. ;)

[poy 0]

No. With NMDC protocol there is always the user guessing. The only way to actually tell which filelist to send, is for each share to have a specific port. So when they $ConnectToMe nick ip:port| you can tell from the port number they connect with, of which filelist to send. :fear:

actually, i already did this and i never had to open multiple ports or anything.

i've changed nothing to the connection part, it's all in ShareManager'translateFileName. there, DC++ chooses which file to send as the file list; you have to give translateFileName the correct parameters so that it just has to pick the list corresponding to the parameter.

in UploadManager::prepareFile, i added the correct parameter to translateFileName this way:

ShareManager::getInstance()->translateFileName(aFile, aSource->getUser()->getTheShareToUseForThisUser());

there is no user guessing, because aSource->getUser() already identifies the correct user, with his hub, etc.

(btw, it's in a DC++ 0.401 based, so it might change a bit in ApexDC++, but something like this should still be possible )

[Pothead 0]

You're wrong. You ever had a look at the hide share code, and the amount of work arounds it has to try and get rid of the "guess-a-user" ? And it still fails occasionally due to Myinfo stripping, and lack of UserIP support.

As soon as you get the same usernames in more than one hub, or the same user with different nicks in multiple hubs, you'll see it going wrong.

here is some reading for you:

http://www.dcpp.net/forum/viewtopic.php?t=474

http://www.dcpp.net/forum/viewtopic.php?t=5927

http://www.dcpp.net/forum/viewtopic.php?t=12415

http://www.dcpp.net/forum/viewtopic.php?t=14814

[poy 0]

you're right on the fact that users with the same nicks can cause some trouble. but look for aSource->getUser() in ConnectionManager.cpp, you'll see this is used for the Pk, Lock, etc. so if this is used and considered good enough in all these places, it can also be used to identify the requester of a file, even if, i agree, it's not always correct when you have the same nick in different hubs.

about "the same user with different nicks in multiple hubs", this isn't much of a problem, he just has to choose the right hub where to ask for your list, and he might get the best one!

one could say there could be trouble on his side, getting "file not available" if his DC++ connects to you via the wrong hub. but this already happens if you use 2 clients with 2 different share on 2 different hubs, but with the same nick on each.

and in your links, i read about some "technical problems" for DC++ to handle different shares. this can be bypassed with the use of vectors/maps/lists/etc.

so your first point is still correct, but i would say "not that important" when you see there is a "hub" column in the transfer view, or in other views too; this "hub" column is usually filled with ClientManager's getUser(), which indeed does some guessing, but it's so widespread that i don't think using it one more time is really a problem.

[Lain_13 0]

How I see it.

What about creating rules for folders and files like access rights on NTFS system, but much simple.

UI:

Hubs is Users in this context. Add box with access rights for all registered in DC favorite hubs under window with folders for sharing. Only one rule - shared or not. One checkbox for every hub. Also add "DEFAULT" value for other (not in favorite) hubs. If folder not shared for some hub - all subfolders isn't shared too.

If access rights changed - TTH information for hubs must be recalculated. Access rules must be stored in special file.

Sending Filelist Procedure:

Add dynamical filter to this procedure! If user from Hub1 trying download filelist from you this procedure may apply access rules to filelist and remove forbidden folders (TTH must be already precached... read ahead for it).

Hashing Procedure:

Add ability to send different user's filelist TTH for different hubs and automatic creating filelist TTH's for hubs after adding/removing files from the list or changing rules. THH information must be cached in additional file... it's can be file with access rules.

...but it's really strong and global changes to code...

...really easy method is using for every specific hub new copy of DC...

...but it's can eat big part of ram and slowing down system (if on all hubs some users start downloading something).

...also it's can eat not-so-small part of HDD space...

...I'm really don't know what eat more processor speed...

...my algorithm or many instances of DC.

...in box with access right's can be created list with profiles (default, profile1, etc.) and profiles can be applyed for one or more hubs in favorite list (dropdown menu in hub properties and additional column in list). This metod can save processor time and it's much flexible. If profile1 apllyed to Hub1 and default profile apllyed to other hub we need recalculate TTH for filelist only for this profiles.