March 4, 2007 3 Comments
Something very important in ADC is the different client identification schemes. I already noted something about them all, but I thought I’d dedicate an entire post for them.
The session ID (SID) is the unique ID that is used per hub. When a client connect to a hub, the hub will assign a particular SID for that user. The SID is calculated by taking 20 arbitrary random bits and then encoding it with Base32 (to a form a 4 byte string). There is only one reserved value that the hub must not assign a user; It is “AAAA”. As the hub isn’t considered a “client”, it does not have a SID. However, to simplify client implementation, the client can (artificially) assign the hub the SID AAAA, since the client know no one else can have that. (Elise and DC++ does this, at least.) During one session, that is, when a user is logged in, the SID for a user mustn’t change. The user must log out and log in to get re-assigned a SID. The SID is assigned before any real information from the client has been sent. This in turn mean that the hub doesn’t care about what kind of information the client send. If the client’s nick change (can happen) during the session, the client won’t get a new SID. Note that the SID is *per hub*. This mean that a user with SID “6DKN” on HubA isn’t necessarily the same user as “6DKN” on HubB (it is possible, however). This ID is what is to be used when sending commands.
This ID is the unique ID that is used to verify your CID (see below). The PID must not be given to another client. Doing so will allow others to claim they’re you. If you’re an operator in a hub, I’m sure you don’t want others to know how to potentially get in and gain that operator-status. Of course, there’s always the possibility of rogue hub operators, but I guess you’ll have to trust them in the end. According to the ADC draft, PIDs should be “generated by hashing the MAC address of the generating client followed by the current time using the Tiger hash algorithm.” Personally, I had a couple of issues with that when I wrote the PID generation for Elise. (1) The MAC address isn’t always that simple to get. If you can’t get to it, just use an arbitrary string that you know will be (at least) semi-unique. (2) “The current time” phrasing is a little fuzzy, since we have no idea of what format that “current time” should be. Seconds since 2000? Time of day? Doesn’t really matter here, either. Make sure you are using something that is (at least) semi-unique. In the waiting for a potential re-phrasing, use strings that make the final hash probably to be unique in the end. Elise do, at least. Note that it is the Tiger hash algorithm. Not Tiger Tree. (I have no idea if it actually really matter here since the info isn’t very large, but worth noting anyway…) The final PID should be 192 bits and encoded with Base32 (to form a 39 byte string). You can actually change your PID to something you’d like in the Experts Only page… Note that this means that the CID will also change.
While having the most ambiguous ID-name, it is also the most important. The CID is the ID that will (should) uniquely identify you across entire DC. The CID is constructed by taking the unencoded hash, hash it again, and then apply the encoding with Base32 (also 39 bytes). This ID is something you will identify yourself for your friends, for the appropriate hub status (registering per CID is a lot better than nick since people can change nick all the time) and as other people’s source.
Changing CID and PID is potentially possible during a session, though there’s a rather large chance that the hub will kick you. (ADCH++ will.)