View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002483 | unreal | ircd | public | 2005-04-15 02:06 | 2013-05-20 09:51 |
| Reporter | w00t | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | duplicate | ||
| Summary | 0002483: "Numerics" instead of nicknames over links | ||||
| Description | Now, before you flame me, I understand this will be a *long* time happening, if at all. I just wanted to enquire as to whether it will happen at ALL, ie the shortening of nicks to (say,) b64 numerics like in ircu, etc. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
| duplicate of | 0004196 | resolved | TS6-style SID/UIDs |
|
|
it's on todo for 3.3* yes. |
|
|
ack'ed, because this has always been on todo for 3.3*. reason was not because it could save bandwidth, but because it would get rid of some desynch issues that otherwise cannot be solved. |
|
|
How might this be implemented? What's the concept/theory behind it? |
|
|
Read up on the TS6, and P10 protocols |
|
|
This presumably would replace servicestamps, right? We'd have a real 'userid' to use to track users, or so I assume. hell, even better if this could be exported to client-protocol somehow. Presumably there would be no way for a user to get the same user-id as another, or have it be the fusion of a 32bit userid and 32bit timestamp, and you should never get two users (at different times) who have the same timestamp + userid. |
|
|
And to make the userid be able to be simply incremented instead of random, you could do this: userid = serverID << 24 || ++baseID; |
|
|
Actually. UserIDs are *EASY* to keep unique. Two words: file descriptors. Put server numeric in upper 8 bits, file descriptor in the remaining (24 | 56) bits. Guaranteed unique, because no two servers can have the same server numeric, and no two users on any given server can *EVER* have the same file descriptor (else they'd have the same socket connection). Put simply: userid = (server->numeric << ((sizeof(int)*8)-8)) | cptr->fd; Assuming MAXCONNECTIONS isn't something insanely big. (edit: This might not work precisely on windows, because IIRC file descriptors aren't flat integers 0 ~ MAXCONNECTIONS, but rather full-blown pointers (32/64-bit address and everything). However, it is my recollection that there's an static global (preallocated) array with all the local clients, so we could use the index for that.) |
|
|
a) I assume we have to choose either uint32 or uint64 b) I want/need a number that is unique over a reasonable timeframe (hours?) w/o worrying about how an ircd leaf restarted multiple times might cause a collision. This is why I want and expect to need a userid _and_ timestamp. |
|
|
and yes, hours is about the limit. maybe even 15 minutes. if a user connects 15 minutes after another user disconnects, i need it to still be unique. at present I get to [ab]use the servicestamp. if the servicestamp is zero, then I assume I have never seen this user before. If the servicestamp is non-zero, and I can find it in my usertable, I assume it's the old user. If I cannot find the servicestamp, I assume I don't know the user and give them a new userid/servicestamp. |
|
|
as a sidenote, we currently expire old user entries after 5-10 minutes, so yeah, 15 minutes is the most _I_ need. |
|
|
Even if a timestamp is involved, collisions cannot be avoided (clocks, for example). If you want securely unique identification, even userid alone won't cut it. You'd need a combination of userid, services stamp, maybe something else like SWHOIS or like ircu has ACCOUNT or something. Or note that the user's being introduced with usermode +r. What you are doing now with the services stamp is exactly what the services stamp is there for (so no you aren't abusing it). It is not what the user numeric is for. User IDs are for basically identification only for as long as the user is visible. It's like a second nick the user has no control over. Once the user's off the userid should generally be regarded as invalid, regardless of why the user is gone (netsplit, whatever). IIRC this is how user numerics work on every ircd that has them (ircu, ratbox I think, also IRCnet IRCD, possibly others). IIRC They don't gauruntee a new user won't have the same ID as the user who quit less than 15 minutes ago. This is, as syzop has said, meant for getting rid of desynchs that otherwise can't be solved. Server numeric and user file descriptor should be good enough for this purpose. As w00t said, read up on those protocols, I recall at least P10 does not say anywhere that user numerics won't be reused within 15 minutes. I don't know about TS6. Depending on such a thing would be depending on nonstandard behavior. (On a slightly related note, this feature could lead to a better way to resolve nick collisions. IRCnet's IRCD just renames the user to 0<numeric> which is impossible to be already used since no one can manually request such a nick except by doing /nick 0 which just makes them 0<their own numeric>. Granted that breaks RFC which says nicks have to start with nondigit, but I doubt IRCnet would've done it if clients broke.) |
|
|
so servicestamp won't go away, and i'll need a separate lookup table for userid->nick lookups. joy. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-04-15 02:06 | w00t | New Issue | |
| 2005-04-15 08:21 | syzop | Note Added: 0009756 | |
| 2007-04-27 06:06 |
|
Status | new => feedback |
| 2007-05-07 12:29 | syzop | Note Added: 0014016 | |
| 2007-05-07 12:29 | syzop | Status | feedback => acknowledged |
| 2007-05-07 19:35 | WolfSage | Note Added: 0014024 | |
| 2007-05-08 03:36 | w00t | Note Added: 0014038 | |
| 2007-05-13 19:16 | tabrisnet | Note Added: 0014123 | |
| 2007-05-13 19:16 | tabrisnet | Note Edited: 0014123 | |
| 2007-05-13 19:30 | tabrisnet | Note Added: 0014124 | |
| 2007-05-13 19:47 | aquanight | Note Added: 0014125 | |
| 2007-05-13 19:49 | aquanight | Note Edited: 0014125 | |
| 2007-05-13 19:52 | tabrisnet | Note Added: 0014126 | |
| 2007-05-13 19:55 | tabrisnet | Note Added: 0014127 | |
| 2007-05-13 20:00 | tabrisnet | Note Added: 0014128 | |
| 2007-05-13 20:40 | aquanight | Note Added: 0014129 | |
| 2007-05-13 21:56 | tabrisnet | Note Added: 0014131 | |
| 2013-05-20 09:51 |
|
Relationship added | duplicate of 0004196 |
| 2013-05-20 09:51 |
|
Status | acknowledged => resolved |
| 2013-05-20 09:51 |
|
Resolution | open => duplicate |
| 2013-05-20 09:51 |
|
Assigned To | => nenolod |
