Sharing Profiles

Use this forum to flesh out your feature request before you enter it in <a href="http://dcpp.net/bugzilla/">Bugzilla</a>.

Moderator: Moderators

Locked
fziec1
Posts: 1
Joined: 2006-02-10 12:34

Sharing Profiles

Post by fziec1 » 2006-02-10 12:39

It would be a good idea to introduce "Sharing Profiles."
Many Hubs have strict rules about shares ( for example, no software ), so each time one wants to connect to them, and one's shares consist of unwanted content, one may be booted.
The profiles, which could be changed in options ( with Shares ), would allow one to specify what kind of shares he wants
For example,
Profile: withS ( name specified by user, of course ) would consist of all shares including software, while noS would consist of all shares but software.
I believe it would be vital, as many times I connect to such hubs, I have to change my share options.

Big Muscle
Posts: 72
Joined: 2004-01-23 14:45

Post by Big Muscle » 2006-02-10 14:06

noooo, never... it would decrease amount of shared data, because a lot of users would share only a requested minimum for that hub.

ullner
Forum Moderator
Posts: 333
Joined: 2004-09-10 11:00
Contact:

Post by ullner » 2006-02-10 16:16

This has been request several times before.

cologic
Programmer
Posts: 337
Joined: 2003-01-06 13:32
Contact:

Post by cologic » 2006-02-11 12:25

Not in NMDC.

cyberal
Posts: 360
Joined: 2003-05-16 05:42

Post by cyberal » 2006-02-11 19:45

this feature would RoXxz0Rz, I can't belive noone has thought of this before!!
http://whyrar.omfg.se - Guide to RAR and DC behaviour!
http://bodstrom.omfg.se - Bodströmsamhället, Länksamling om hoten mot vår personliga integritet

Xan1977
Forum Moderator
Posts: 627
Joined: 2003-06-05 20:15

Post by Xan1977 » 2006-02-11 19:50

Hehe

psilorder
Posts: 1
Joined: 2006-03-17 09:17
Contact:

Post by psilorder » 2006-03-17 09:22

profiles would be the best and secondbest would be if you could choose/remove individual files (hey, why not both?)

imb
Posts: 99
Joined: 2004-06-15 17:48
Location: England

Post by imb » 2006-03-17 16:06

So if you have a user who shares 5GB in one place, and a 100 in the other, you'd be puzzled as to why he never had a slot in the 5gb place?

SubversiveAgent
Posts: 53
Joined: 2006-03-27 06:11

Post by SubversiveAgent » 2006-03-27 07:31

To be quite honest, this feature is only relevant if you want to share porn

I see no great loss in implementing it. In regards to the use of this feature for "cheating" on your shares... If you have 100GB worth of stuff to share, why only share 5GB? It's not like your slots won't get grabbed all the same.

ivulfusbar
Posts: 506
Joined: 2003-01-03 07:33

Re: Sharing Profiles

Post by ivulfusbar » 2006-03-27 07:58

fziec1 wrote:It would be a good idea to introduce "Sharing Profiles."
Many Hubs have strict rules about shares ( for example, no software ), so each time one wants to connect to them, and one's shares consist of unwanted content, one may be booted.


Agreed, in NMDC you can only have one profile / session. I.e. you need to use the same share in all hubs your are online on. This can very simply be achived by a trivial bat-file which copies the wanted xml-settings files (dcplusplus.xml) to your dc++-installation-directory before running dcplusplus.exe. It is simple and will run smoothly. Only issue is that you will have to restart dcplusplus.exe if you want to use another sharing-structure. Another simple solution is to use fancy mounting-points in your filesystem and do "virtual directories" (junctions), see http://support.microsoft.com/?kbid=205524 for example. The it would only be a matter of choosing which directory to choose.

In ADC, different shares in different hubs might get implimented since it support the logic to accomplish it, which NMDC lacks.
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.

Pothead
Posts: 223
Joined: 2005-01-15 06:55

Post by Pothead » 2006-03-27 11:14

dcplusplus changelog wrote:-- 0.68 2006-01-08 --
* Changed the user identification process completely to work better with ADC. This leads to a more strict interpretation of
which users are actually the same for NMDC (essentially, NMDC users are now identified by nick+hub always, not only nick)
I thought this would have sorted the issue with NMDC protocol.
True it would require everyone else running that version or later as well. Maybe something like what Trem did with, "Client too old, not supported", would need to be added as well though. (Maybe better based on version in PK string, instead of disallowing $Get.)
This will in turn make users victims of stupid op's on cdm's based on old clients, who don't appreciate that the minimum version of dc++ allowed should be increased. :roll:
Before anything like that dc++ will have to have a version later than 0.674, which is classed as stable. :)

So while it should be possible with nmdc hubs, it's not recommended for a long time. Whereas with adc it should be fine already.
And hopefully during that "long time" the majority of hubs will switch from nmdc to adc hubs, meaning that it won't actually need to be done. Lazyness rules. :D

cologic
Programmer
Posts: 337
Joined: 2003-01-06 13:32
Contact:

Post by cologic » 2006-03-27 12:33

No. It's still a protocol issue, regardless of slightly less ugly hacks in DC++.

Pothead
Posts: 223
Joined: 2005-01-15 06:55

Post by Pothead » 2006-03-27 18:58

If you know the ip and port of the hub which sends the CTM's, RCTM's and searches, and all the clients are sending through the right hub (why i think 0.68 should be min version), how can it go wrong ?

ivulfusbar
Posts: 506
Joined: 2003-01-03 07:33

Post by ivulfusbar » 2006-03-28 00:31

Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2006-03-29 12:00

Pothead wrote:I thought this would have sorted the issue with NMDC protocol.

The problem is only partially with DC++'s internal state. The other half of the problem is that the connecting side offers you nothing more than their nickname to identify themselves. So if users with the same nick exist on multiple hubs, you have a problem guessing which is which when they connect (passive) or you connect (active) to them and ask for a file.

SubversiveAgent
Posts: 53
Joined: 2006-03-27 06:11

Post by SubversiveAgent » 2006-03-29 14:15

GargoyleMT wrote:
Pothead wrote:I thought this would have sorted the issue with NMDC protocol.

The problem is only partially with DC++'s internal state. The other half of the problem is that the connecting side offers you nothing more than their nickname to identify themselves. So if users with the same nick exist on multiple hubs, you have a problem guessing which is which when they connect (passive) or you connect (active) to them and ask for a file.


? What's that unique TTH ID that shows when I do the "about DC++" bit then ?
I want your slot.

joakim_tosteberg
Forum Moderator
Posts: 587
Joined: 2003-05-07 02:38
Location: Sweden, Linkoping

Post by joakim_tosteberg » 2006-03-29 14:31

That is the TTH hash of the DCPlusPlus.exe file and as such it will be the same for all users of the same version ;)

PseudonympH
Forum Moderator
Posts: 366
Joined: 2004-03-06 02:46

Post by PseudonympH » 2006-03-29 15:00

Well, probably not including those that compile it themselves. :)

Quattro
Posts: 166
Joined: 2006-01-11 09:23

Post by Quattro » 2006-03-29 15:46

PseudonympH wrote:Well, probably not including those that compile it themselves. :)


if every file stays the same including stl and wtl and all the other includes...
it should have the same hash...
or else VS add's other stuff to the program :P
You can send a message around the world in 1/7 of a second; yet it may take several years to move a simple idea through a 1/4 inch of human skull.

Pothead
Posts: 223
Joined: 2005-01-15 06:55

Post by Pothead » 2006-03-29 19:26

GargoyleMT wrote:
Pothead wrote:I thought this would have sorted the issue with NMDC protocol.

The problem is only partially with DC++'s internal state. The other half of the problem is that the connecting side offers you nothing more than their nickname to identify themselves. So if users with the same nick exist on multiple hubs, you have a problem guessing which is which when they connect (passive) or you connect (active) to them and ask for a file.
Thanks well explained :) I was guessing towards that after from reading one fusbar's posts on http://dcpp.net/forum/viewtopic.php?p=43566 quite a few times. (which fusbar quoted :))

Only thing i can think of to sort that, is some sort of memory for ctm's/rctm's and then compare nicks when actual client connection is estabilished.

The GetCID support i've seen in Zion++ could also be useful. But to use that to sort this would also require hubsoft changes to support sending CID instead of nick in the ctm's / rctm's.

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2006-03-30 08:13

Pothead wrote:Only thing i can think of to sort that, is some sort of memory for ctm's/rctm's and then compare nicks when actual client connection is estabilished.

Yes, keeping state like that would allow you to successfully guess most of the hubs correctly. However, if you have two passive users with the same nick, you're stuck - they'll both be incoming connections. You'd have to potentially delay responding to one until the other had connected. Messy.

And if people start connecting directly to your IP/TCP_Port, all bets are off, unless you keep track of the IP on first connection. And even that will break if the user is on two different hubs with you, and each hub has a different share profile.


The trick in most features is seeing how you can break it, not how you can make it possible. Usually making it possible is the 'easy' part, and the breaking requires a devious mind. (But leads to a better implementation -- or at least understanding.)


As an aside, this is why CTMs in ADC are designed the way they are. The token would let you handle all of the above situations nicely.

joakim_tosteberg
Forum Moderator
Posts: 587
Joined: 2003-05-07 02:38
Location: Sweden, Linkoping

Post by joakim_tosteberg » 2006-03-30 14:52

Quattro wrote:
PseudonympH wrote:Well, probably not including those that compile it themselves. :)


if every file stays the same including stl and wtl and all the other includes...
it should have the same hash...
or else VS add's other stuff to the program :P
I wouldn't expect them to have. Just change one tiny little compiler option and you have a new TTH hash ;)

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2006-03-31 08:20

joakim_tosteberg wrote:I wouldn't expect them to have. Just change one tiny little compiler option and you have a new TTH hash ;)

Just compile at a different time, and you have a new TTH hash.

Compile time is part of the PE-header in the executable.

(Thanks for replying, I missed that statement by Quatto, or I would've added that in my last reply.)

Quattro
Posts: 166
Joined: 2006-01-11 09:23

Post by Quattro » 2006-04-03 04:25

ah i see, didn't know that... i know DCH++ does it. so it makes sense DC++ would too =)
You can send a message around the world in 1/7 of a second; yet it may take several years to move a simple idea through a 1/4 inch of human skull.

apanola
Posts: 1
Joined: 2006-04-13 08:40

Post by apanola » 2006-04-14 05:28

SubversiveAgent wrote:To be quite honest, this feature is only relevant if you want to share porn


That's exactly what I want it for :lol:

SubversiveAgent
Posts: 53
Joined: 2006-03-27 06:11

Post by SubversiveAgent » 2006-04-17 05:08

You and everyone else ;)
I want your slot.

Locked