Verlihub ⋅ NMDCWelcome to unofficial NMDC specification for newly invented protocol extensions that are probably not documented elsewhere, but yet they are very effective in some cases. It is up to you to make your hub or client to become more effective in a few ways described below. Please refer to official documentation for general protocol specification.
Table of contents
HubINFOContext: Hub > Pinger
Hub is allowed to send HubINFO command to hublist pinger, where 11'th parameter specifies the character encoding currently being used by hub. Here is an example of such command:
Code$HubINFO Nemesis$nemesis.te-home.net$Team Elite Public$64000$0$1$0$Verlihub$Team Elite$Public$CP1251|
Currently our hublist allows usage of following character encodings:
CodeCP1252 - Latin - West Europe
CP1251 - Cyrillic
CP1250 - Latin - Central and East Europe
GB18030 - Chinese
UTF-8 - Unicode
This is required for hublist to correctly convert strings to UTF-8 for proper character display. Hubs that don't specify their character encoding are most likely to be displayed with unreadable names.
NickRuleContext: Hub > Client, Hub > Pinger
This extension specifies list of nick rules currently being used by hub configuration. The command is sent from hub to client right before the nick is about to be validated. Specify NickRule support flag to show compatibility. Here is an example of such command:
Code$NickRule Min 3$$Max 64$$Char 32 60 62$$Pref [ISP1] [ISP2]|
Min specifies minimum nick length. Max specifies maximum nick length. Char specifies space separated list of decimals forbidden to use in nick. Pref specifies space separated list of nick prefixes required for usage in the hub. Not all of the above parameters must be specified, the list is based on hub configuration. Client has a chance to automatically update its nick before sending ValidateNick command. Clients that support NickRule but send invalid nick anyway, will receive BadNick command with error specification:
Nick is too short$BadNick Min 3|
Nick is too long$BadNick Max 64|
Bad characters found in nick$BadNick Char 60 62|
Bad prefix found in nick$BadNick Pref|
One of prefixes missing in nick$BadNick Pref [ISP1] [ISP2]|
Client should then automatically correct its nick and reconnect to the hub. Meaning of this extension is to avoid extra reconnects when nick usage is heavily restricted. This applies only to non registered nicks.
SearchRuleContext: Hub > Client
This extension specifies list of search rules currently being used by hub configuration. The command is sent from hub to client right after the user is successfully logged in. Specify SearchRule support flag to show compatibility. Here is an example of such command:
Code$SearchRule Min 3$$Max 256$$Num 1$$Int 4$$IntPas 6$$Share 10737418240|
Min specifies minimum search string length. Max specifies maximum search command length. Num specifies number of searches available for use during a period of time. Int specifies the period itself in seconds for active search requests for current user profile. IntPas specifies the period in seconds for passive search requests for current user profile. Share specifies minimum share size in bytes required for search for current user profile. Not all of the above parameters must be specified, the list is based on hub configuration. Client has a chance to automatically update its search interval settings for each hub, compare its share size with required size and prepare other kind of actions before sending any search request commands. Int and IntPas might be set to 0 which means that user is actually allowed to search without time limit, and might be set to -1 which means that user is not allowed to use search at all due to low profile or any other kind of restrictions.
Meaning of this extension is to avoid extra search requests to the hub, which are not going to bring any search results to the client anyway.
SetIconContext: Hub > Pinger, Hub > Client
This command specifies hub icon URL to display on hublist or hub tab in some clients. The display size of icon must be relatively small, our hublist for example, downsizes the icon to maximum of 16x16 pixels. Currently only HTTP and HTTPS protocol links can be used with our hublist, but other protocols might be supported by other hublist pingers. For security reason only image/* MIME types can be used as specified here. Here is an example of such command:
Hub can also send SetLogo command to set hub logotype. Similar rules apply to this command, except that image display size is not limited, it's up to hublist to downsize the image to any size that fits best on hub information page. Here is an example of such command:
Both commands are usually sent at the same time before HubINFO command, because usually hublist pingers disconnect from the hub right after they receive the HubINFO command, that way they will not miss your image links. This extension should be strengthened with some kind of support flag, but that is yet to accomplish.
HubURLContext: Hub > Client, Client > Hub, Hub > Pinger, Pinger > Hub
This extension allows the client to specify hub URL currently being used for connection to the hub. Specify HubURL support flag to show compatibility. Hub sends following request to the client sometime during the handshake:
Client replies with following command:
Client should not spend any resources on parsing the URL, it is enough to use the getHubUrl() method as is. Meaning of this extension is to collect statistics about hub addresses being used in a hub by its users, and also to extend address checking functionality to redirect users to most preferable hub address or port. The idea was also to implement SetHubURL command to specify preferable hub address without need to reconnect to the hub, in case it was accessed from hub favorites list. We are hoping to finish this last part of the implementation very soon.
TTHSContext: Hub > Client, Client > Hub
This flag specifies supports for short TTH search commands. Specify TTHS support flag to show compatibility. Not to be confused with TTHSearch support flag. Both hub and client send following commands:
Active search request$SA LWPNACQDBZRYXW3VHJVCJ64QBZNGHOHHHZWCLNQ 188.8.131.52:5|
Passive search request$SP LWPNACQDBZRYXW3VHJVCJ64QBZNGHOHHHZWCLNQ RoLex|
Here you can see the difference from old fashion TTH search commands:
70 vs 54 bytes$Search 184.108.40.206:5 F?T?0?9?TTH:LWPNACQDBZRYXW3VHJVCJ64QBZNGHOHHHZWCLNQ|
70 vs 50 bytes$Search Hub:RoLex F?T?0?9?TTH:LWPNACQDBZRYXW3VHJVCJ64QBZNGHOHHHZWCLNQ|
Meaning of this extension is to save some server upload bandwidth by shortening down the most frequently sent command in outgoing protocol of a hub. Here are some statistics regarding these commands comparing to old fashion commands:
Code[*] $Search: 344579
[*] $Search Hub: 379696
[*] $SA: 243379
[*] $SP: 292746
[*] Total upload: 127.32 GB [395.34 KB/s]
[*] Upload saved with zLib: 44.52 GB
[*] Upload saved with TTHS: 6.29 GB
CTM2HUBContext: Client > Hub
This parameter is sent inside the Error command by hub to client that is trying to connect to a hub in client to client connection request. Such requests are knows as CTM DDoS attack. Here is an example of such command:
Client should immediately disconnect from the server, add the address of requested server to blacklist and ignore any further connection requests to that address during whole remaining session. Meaning of this parameter is to stop the DDoS attack already on client level, regardless of how it was initiated. The idea of using the parameter specifically inside the Error command, is to stop clients that don't support this parameter from connecting to the server, because DC++ instantly disconnects when it receives Error command regardless of the parameter.
MyINFOContext: Client > Hub, Hub > Client
According to DC++ source code, any user who is not sending connection type in MyINFO, is being registered as bot in user list. Here is an example of command without connection type:
Code$MyINFO $ALL Hub-Security Hub security$ $$$0$|
So far it is only known that clients support this, hubs on the other hand are not detecting such users as bots.
MyIPContext: TLS proxy > Hub
Verlihub supports TLS proxy since version 220.127.116.11. Proxy server sends this command to the hub for identification of IP address and TLS version of the client right after connection is made. Here is an example of command:
Code$MyIP 18.104.22.168 1.2|
In case the client is not connected via TLS, which is supported by proxy server aswell, it advertises 0.0 as version number. The hub then updates IP address of connected user and carries out the NMDC handshake in regular order.
TLSContext: Hub > Client, Hub > Pinger
Verlihub displays support for TLS encrypted client to hub connection since version 22.214.171.124 in the $Lock. Here is an example from TLS enabled hub:
Code$Lock EXTENDEDPROTOCOL_NMDC_TLS_1234 Pk=Verlihub 126.96.36.199|
Non TLS enabled hubs send following command:
Code$Lock EXTENDEDPROTOCOL_NMDC_1234 Pk=Verlihub 188.8.131.52|