Verlihub ⋅ NMDC

Welcome 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

1. HubINFO
2. NickRule
3. SearchRule
4. SetIcon
5. HubURL
6. TTHS
7. CTM2HUB
8. MyINFO
9. MyIP
10. TLS

HubINFO

Context: 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:


Currently our hublist allows usage of following character encodings:


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.

NickRule

Context: 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:


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:






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.

SearchRule

Context: 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:


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.

SetIcon

Context: 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.

HubURL

Context: 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.

TTHS

Context: 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:



Here you can see the difference from old fashion TTH search commands:



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:

CTM2HUB

Context: 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.

MyINFO

Context: 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:


So far it is only known that clients support this, hubs on the other hand are not detecting such users as bots.

MyIP

Context: TLS proxy > Hub

Verlihub supports TLS proxy since version 1.2.0.5. 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:


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.

TLS

Context: Hub > Client, Hub > Pinger

Verlihub displays support for TLS encrypted client to hub connection since version 1.3.1.2 in the $Lock. Here is an example from TLS enabled hub:


Non TLS enabled hubs send following command:

Kommentarer

There are no comments for this page, you can leave one here.