TS6 ID's

Bill Bierman bill at mu.org
Tue Feb 22 19:23:39 EST 2005

Rachel Llorenna wrote:

>I'm curious as to why the TS6 documentation
>(http://www.leeh.co.uk/ircd/TS6.txt) chooses to use only capital
>letters and numbers for ID's, effectively making them case
>insensitive. It would greatly increase the number of available unique
>ID's to use both upper- and lowercase, would it not? Then, you could
>reduce the number of characters and maybe save a few bytes of
>bandwidth per user.
>Current ID implementation (6 bytes):
>1572120576 users per server
>(This of course assumes that I understand ID's correctly, in that ID's
>need to be unique to servers only, since they will always be unique to
>the network when prefixed with the SID)
>My proposed idea (4 bytes):
>12393056 users per server
>This is a huge amount and should be sufficient on a per-server basis
>for many, many years to come. Also, remember that these are only ID's,
>full UID's will be 3 characters longer since they have the SID
>We could also modify the SID's to use only two characters:
>620 servers (It's unrealistic to have more than this on a production network..)
>7683694720 users per network
>Perhaps, though, this has something to do with the way in which the ID
>hashes are set up.  Still, I somehow doubt that we would ever need
>enough ID's for 1572120576 users per server.
Currently, there are 12960 possibilities for SIDs.  This is certainly 
more than enough.

There are also 1572120576 possibilities for users.  This gives a 
possible user capacity of 20374682664960 users. (Rougly 3200 times the 
population of the world).  Certainly this is plenty.

The reason for all upper case (if I remember correctly) is actually two 
reasons.  First, consistency.  The original RFC and historic IRC Daemons 
accepted commands only in upper case.  Secondly, in terms of parsing, 
case sensitive is much faster.  If you need not deal with both A-Z and 
a-z, and distinguish between them (which you would have to do, under 
what you're suggesting), things will go much faster.

If you are concerned with bandwidth, I would suggest using compression.


More information about the hybrid mailing list