Ideas to identify a user within userconnection

xayide · Post by **xayide** » 2003-07-13 05:58

If u are in like 3 hubs and there exists 3 years with the same nick, one in each of these hubs. And u send ConnectToMe to one of them. How in earth would u make it possible to tell him aport from the others once he connects to your client? I mean there is no real way build in to dc++ to know which hub/user this connection originates from. Anyone have ideas to make it more reliable?

Sedulus · Post by **Sedulus** » 2003-07-13 09:33

you could use one listening port per hub..
I think QuickDC does that.. I've heard Offset talk about it at least

cologic · Post by **cologic** » 2003-07-13 10:21

Doesn't work in passive mode (obviously).

xayide · Post by **xayide** » 2003-07-13 10:36

>If u are in like 3 hubs and there exists 3 years with the same nick

LOLS!! hehe wtf did I wrote? "users" ofcourse.

Sedulus yeah that has been suggested by fusbar before. though one thing that doesnt work with that idea is passive mode. Or does it?

qqzm · Post by **qqzm** » 2003-07-13 14:13

DC++ currently allows different nicks for different hubs, so how does it know which nick to use when a connection comes in?

Sedulus · Post by **Sedulus** » 2003-07-13 15:10

the incoming connection sends his/her nick first,
User::Ptr& ClientManager::getUser(thatNick) is consulted
that User has a specific hub, hence we know our name
(this will give conflicts when two nicks are the same in different hubs, yes)

xayide · Post by **xayide** » 2003-07-13 15:11

its the other way around. It knows which nick comes in. But it cant tell from which hub. So if the same nick exists in more than one of the hubs your are connected to. Then u are in for trouble. Thats what has to be solved.

cyberal · Post by **cyberal** » 2003-07-14 00:54

and the solution is ofcourse to include hubname/hubaddy in the connection attempt.. how this can be done however, i leave to you

qqzm · Post by **qqzm** » 2003-07-14 02:13

Possible solution:

A and B are clients, A sends a $ConnectToMe to B. B receives this through hub X and starts the connection.
Add an item to the $Supports list called "HubID". If both clients support this then client B sends a command sometime in the handshake of the following form:

Code: Select all

$HubID <Hub IP>:<Hub Port>|

So now both clients know which hub the connection was made through.

cyberal · Post by **cyberal** » 2003-07-14 03:07

yes exactly, this can't be very hard to do. Make this happen and the biggest problem is solved.. GREAT!

xayide · Post by **xayide** » 2003-07-15 08:05

hehe I had those thoughts too earlier. Though it has to be changes done to the protocoll and that is not my intent, so there has to be some other way od doing this right.

ivulfusbar · Post by **ivulfusbar** » 2003-07-18 05:40

no, $HubId with hubip and hubport can not be used, many hubs are multihomed. Mine and xayides "home" hub for example. And more and more hubs supports more than one port to make sure that users with ivul isps can still connect.

We have discussed this before, and i think if this is needed, a extension to the protocol must be made, and then you get into extension of the protocol. Either in the connections-commands in the hub-client protocol or in a pure CTCP-devolopment solution (ooh.. i wonder how many times i have talked about CTCP here.. ;)) )

it-can-be-solved-in-so-many-ways-but-most-of-them-cost-alot-ly'ers.

cyberal · Post by **cyberal** » 2003-07-18 05:51

but there must be a way to solve the situation where two users that will connect to eachother are connected to the same hub via different ports, in such a situation.. can't the app just ignore the hub port and match it to the addy alone? Ah well, ofcourse.. that same user could potentially be connected to a different hub on the same ip.. not very likely though..