CID: When to (not) rely on them

Here is the sub forum used for talking about ideas, implementations and suggestions or typical guidelines.

Further info on extension or the protocol is found at our Wiki
Locked
Ayo
Junior Member
Posts: 27
Joined: 23 Feb 2011, 13:50

CID: When to (not) rely on them

Post by Ayo » 02 Jul 2011, 08:45

So ADC provides a means to uniquely identify a client across multiple hubs, using the concept of a CID. While it's conceptually very nice, from the perspective of a client it's hard to determine in which cases it is safe to rely on them, and in which cases it definitely isn't. In this topic I'm trying to clear up this confusion (for myself, mostly) and was wondering what you guys think of these things.

Connection Management
So far I have not seen a problem with using CIDs for C-C connection managent. This includes making sure there are not too many connections with the same client and stuff like slot granting. Slot granting can be implemented quite safely by just keeping the CID of the granted client and matching against the ID parameter sent in the connection.

Private Messaging
Now suppose a client has a global "Favourite users" list where each user is again identified with a CID. Suppose you want to initiate a PM chat with said user and find that he/she is online on multiple hubs. According to this recent interview, it's not safe to rely on the idea that both hubs will do just fine.
Conclusion: Need to use hub+CID as user identification here, to be safe.

Download Management
I am not yet aware of any client that implements per-hub shares, but have certainly seen it being mentioned a few times. In the case that a client does implement that, it would mean that CIDs alone can also not be used to identify which client has a particular file.
Conclusion: Again, need to use the hub+CID as client idenfitication in the queue/download code.

Any comments? Things I've missed so far?

poy
Member
Posts: 78
Joined: 26 Nov 2008, 17:04

Re: CID: When to (not) rely on them

Post by poy » 03 Jul 2011, 15:34

there are hubs that block connections, or ones you may just not want to send connection requests on because they are not encrypted; so it's better to always respect the hub an action originated from, whichever that action may be.

DC++ uses hubs as "hints": when an action has been initiated from a hub, it will do its best to accomplish all following operations on the same hub; but when it can't, it may fall back to another hub where a user with the same CID is connected.

the fallback mechanism isn't quite perfect yet and may even be undesirable in cases like private messages. i would shift your concerns from "when should the client use hub addresses as an addition to CIDs?" to "the client should always use hub addresses; when should it not be allowed to fall back to other hub addresses?".

Ayo
Junior Member
Posts: 27
Joined: 23 Feb 2011, 13:50

Re: CID: When to (not) rely on them

Post by Ayo » 03 Jul 2011, 17:37

Yeah, I've currently switched to the other extreme: now using the (cid, hub) pair for everything. That at least guarantees that nothing will go wrong in that aspect. I can always make better use of CIDs and possibly provide fallbacks later on.

klondike
Member
Posts: 73
Joined: 14 Nov 2010, 13:06

Re: CID: When to (not) rely on them

Post by klondike » 04 Jul 2011, 01:04

Well I personally don't quite like CIDs specially now that ECDH is out and djb's curve25519 is out and no patent claims have been presented against users.

I have written some propossals to fix that but they have been scrapped by a bad computer U_U. Once I get cheered up enough I will try again.

Locked