My client performs the regular login sequence (with "$Supports NoGetINFO NoHello UserIP2"), waits for its own $Hello and then replies with a $GetNickList. The results below are what I received after that. I've not listed the $UserCommand messages which almost every hub sends regardless of whether you have "UserCommand" in your $Supports. I've compressed all $MyINFO messages of other users to a "$MyINFO ..". This listing does not include a $MyINFO for the connecting client, unless otherwise noted. "$MyINFO self" is the $MyINFO of the connecting client.
Code: Select all
Ptokax 0.4.1.2 and 0.4.2.0: - $HubName - Hub version chat message - $MyINFO ... - $MyINFO self - $OpList - $UserIP self - MOTD FlexHub (Beta 0.2 svn: 1365 and 1409) - $HubName - $MyINFO .. (first batch) - $MyINFO self - $OpList - $UserIP self - MOTD - $MyINFO .. (second batch) - $MyINFO self - $BotList - $OpList (duplicate) Open DC Hub 0.8.2: - MOTD - $NickList > $GetINFO .. - $OpList - $MyINFO .. (same order as requested) (No support for $UserIP) DB Hub (version unknown): - $MyINFO self - MOTD - $MyINFO .. - $OpList (No $UserIP, despite the hub indicating support for it) Verlihub 0.9.8e-r2 and 0.9.9a: - $UserIP self - MOTD - $HubTopic - $MyINFO .. - $MyINFO self - $OpList - $MyINFO self YnHub 1.036: - $HubName - MOTD - $OpList - $MyINFO .. (including self, sorted ASCIIbetically) - $UserIP self
While it's possible to detect when you've got the entire user list for each individual hubsoft, there doesn't seem to be a common order between all hubs. So I've decided to stick with the following (simple and stupid) policy: The user list is "complete" when either a) We've received a $MyINFO from a user of which we've already received a $MyINFO before or b) 10 seconds have passed since the last $MyINFO we received. a) works perfect for Verlihub and Flexhub, which send your own $MyINFO twice. It also works for large hubs where user info tends to change fast. In other situations, the timeout guarantees that something happens, and hopefully hubs and networks are fast enough to not trigger the timeout while sending the userlist. It's not the best policy, but simple enough for now.