I'm reading the ADC spec in order to implement it, and I'm just wondering: The spec doesn't appear to contain any rationale for including both a PID and a CID. I can merely guess that the purpose of the PID is for authentication -- is that correct, or is it used in other/more situations?
Furthermore, the spec appears to mandate the use of the MAC address in generating the PID. I might be guessing incorrectly, but the goal is merely it being unique, right? In that case, one should be able to just read 24 bytes from /dev/random instead (or the Windows analogy).
Also, while I'm at it, I'm wondering if there's any specific purpose of defining the SID and its base32-encoded version separately. Is there any particular reason for not just defining it as 4 arbitrary characters instead of a 20-bit number?
PID and CID
Moderator: Moderators
-
- Posts: 506
- Joined: 2003-01-03 07:33
The rationale for including both PID and CID is that another client should not be able to steal another client CID. PID is only used in client-->hub communication. The PID is never broadcasted by the hub to other clients. Ofcourse, someone with access to the hub can steal a clients CID by examining the raw data. So PID is only used to create a global ID that should not be to simple to duplicate from a client.
The PID should be unique, and doesn't have to come from the MAC. It should only be an recomendation. The PID should only be created once, and then be used globaly over hubs and over sessions.
We want to use BASE32 for consistency in the SID. Any particular reason more than that? Not much. but 4 chars in base32 should be enough for most hubs.
The PID should be unique, and doesn't have to come from the MAC. It should only be an recomendation. The PID should only be created once, and then be used globaly over hubs and over sessions.
We want to use BASE32 for consistency in the SID. Any particular reason more than that? Not much. but 4 chars in base32 should be enough for most hubs.
Re: PID and CID
Getting a well-defined specification is unfortunately often not as simple as that. ADC uses utf8 encoding for general text and "4 arbitrary characters" wouldn't necessarily have a 4 byte representation in the stream. I'm sure you will agree that this would unnecessarily complicate the implementation. Base32 is just an alphabet limitation that is already used in other parts of the protocol and comes in handy here. On the bright side, an implementation can just handle the SID as you suggest and the size was intentionally chosen to allow that.Dolda2000 wrote:Also, while I'm at it, I'm wondering if there's any specific purpose of defining the SID and its base32-encoded version separately. Is there any particular reason for not just defining it as 4 arbitrary characters instead of a 20-bit number?