Different sharing on different hubs.
Moderator: Moderators
Different sharing on different hubs.
In the list favo hubs, I think it would be good to have different share definitons. On some hubs there are only films. Other not mp3 or software.
So it would be very good to have some speciall shareing for speciall hubs.
Now I have to use the smallest common accepted share folders. So I can not be on mp3 hub and searching and at the same time share my films on a film hub. (Or downloading films) Since the limits often are very dfferent on films and mp3 hubs!
So it would be very good to have some speciall shareing for speciall hubs.
Now I have to use the smallest common accepted share folders. So I can not be on mp3 hub and searching and at the same time share my films on a film hub. (Or downloading films) Since the limits often are very dfferent on films and mp3 hubs!
-
- Posts: 8
- Joined: 2003-04-27 18:33
- Contact:
That bad. Well it's opensource. I guess if its a good ide someone will do it. In DC++ or a other klient. Since there are ways to get around the problem, there is no idea to have the opinion that is a bad idea. People use the workarounds and only think it's crappy software. I use XP and run
different DC++ klients as firrent users. So its only overhead. Good software don't force people to do extra overhead becuse of silly limitations. If it's hard technical problem we may have to stick with
the limitation, otherwise a sucessor will take DC++ place. Not today,
but it will happend.
different DC++ klients as firrent users. So its only overhead. Good software don't force people to do extra overhead becuse of silly limitations. If it's hard technical problem we may have to stick with
the limitation, otherwise a sucessor will take DC++ place. Not today,
but it will happend.
-
- Posts: 506
- Joined: 2003-01-03 07:33
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
If you read the other threads, you'll find that per-hub shares do have their difficulties (like the earlier poster says). When you're running two clients with two shares, you don't see the problem this scenario: two identical nicks on two hubs that have different shares both connect to you. How do you know which share to give to which user? At that point in the conversation, all you have is a nick and an IP. You cannot tell from which hub they came.megla wrote:Since I run two clients at the same time now. They have diffrent shares.
That's a very good proof that it is possible. It's maybe hard, and maybe not worth it. But for sure not impossible.
That is the problem.
Does the assertion that it's hard make sense now?
See http://dcplusplus.sourceforge.net/forum ... php?t=4446 for more detail about it. It's mostly aimed at those who understand the DC++ code some, but it sheds a bit of light on the issue.
GargoyleMT: No it dont. When you have two clients they listen to two different ports. So if two people with the same nick ask for a share you know what shareset you are shareing on that port the request is commit to. That's the way it works for two process running DC++, and that's the way it coult work in one client listen on two (or more) ports. Thus, the proof is still correct.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
what it comes down to is that the DC client have lots and lots of information about all users in all hubs it is in. BUT, it does not know what users are in what hub. Solve that, and we can move on.
include hubip+port in MyInfo?
include hubip+port in MyInfo?
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
http://bodstrom.omfg.se - Bodströmsamhället, Länksamling om hoten mot vår personliga integritet
(1) Yes, opening multiple listening ports 'solves' the problem for active users. However, it doesn't for passive users, and allowing such a large gap in functionality between the two would be unseemly.
(2) As far as cyberal's suggestion, what about multihomed hubs? Better is to have $CTM pass on a randomly generated token/cookie that's passed pack to the uploader upon connection so it can identify the hub it came from.
(2) As far as cyberal's suggestion, what about multihomed hubs? Better is to have $CTM pass on a randomly generated token/cookie that's passed pack to the uploader upon connection so it can identify the hub it came from.
cologic: For me it's a good thing with more functionality for people that do not use passive mode. If everyone was using passive mode we get in to
big problems. And if it was up to me, we could ban the passive mode if it was making my functionality better. I don't think it do things worse so it can stay. My respect to hubownsers that ban passive. Just my opinion
big problems. And if it was up to me, we could ban the passive mode if it was making my functionality better. I don't think it do things worse so it can stay. My respect to hubownsers that ban passive. Just my opinion
the amount of users that CAN'T go active is big, a solution that excludes passive users is no good, half the swedish university network are passive and they can do nothing to change it!
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
http://bodstrom.omfg.se - Bodströmsamhället, Länksamling om hoten mot vår personliga integritet
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
I'm sorry, I don't quite get what you mean about "passive ports." It sounds like you're getting Active mode's port (i.e. a listening port on the local machine) and Passive mode (no listening socket, all connections are initiated as outbound connections) mixed up.megla wrote:It don't matter if they are on passive or active ports. If they are on passive ports they get there requests from a tcp-socket.
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
You get a request from one of the hubs. You do an connection to the other host. You know what hub that user request is from, and then you can send the correct filelist for users on that hub. So it makes no difference if you are on passive or active mode. You can have the different file lists for each hub in both modes. So it's not a valid cause to not having diffrent files to different hubs.
no, thats the problem.. the client DON'T know this..megla wrote:You know what hub that user request is from, and then you can send the correct filelist for users on that hub.
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
http://bodstrom.omfg.se - Bodströmsamhället, Länksamling om hoten mot vår personliga integritet
different portnumber?
no?
no?
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
http://bodstrom.omfg.se - Bodströmsamhället, Länksamling om hoten mot vår personliga integritet
If I understand correctly, the client doesn't know which hub the other users are in, especially if they are in multiple hubs
But the hub in which the result was obtained from is displayed in the right-most column of the search window. I don't get it.
Would it be possible for the nick system to change slighty so that your nick is hub+nick, and therefore your nick would be different for every hub? I forsee problems with this approach...hell, it might not even be helpful.
What is wrong with my logic?
But the hub in which the result was obtained from is displayed in the right-most column of the search window. I don't get it.
Would it be possible for the nick system to change slighty so that your nick is hub+nick, and therefore your nick would be different for every hub? I forsee problems with this approach...hell, it might not even be helpful.
What is wrong with my logic?
Hehe.
-
- Posts: 506
- Joined: 2003-01-03 07:33
Is the best solution to the problem, better than yours jbyrd..cologic wrote:(1)
(2) As far as cyberal's suggestion, what about multihomed hubs? Better is to have $CTM pass on a randomly generated token/cookie that's passed pack to the uploader upon connection so it can identify the hub it came from.
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.