NMDC: The run down

I’ve been advocating ADC because of NMDC’s shortcomings. However, I haven’t gone through how NMDC is built up. I thought I’d do that today.

Neo-Modus Direct Connect (NMDC) was created in November 1999 by Jonathan Hess, while still being in high school (am). Hess never released information about the protocol, or the source code for his client or hub, which forced others to reverse-engineer each of those things, thus an official specification has never arisen.

NMDC is a text-based protocol, meaning that you don’t need commands to go through an algorithm for you to understand the command. This means also that commands have certain delimiters which indicate when a command end, a new start etc. $ (dollar sign) is used to denote that there’s a new command. | (pipe) is used to denote the end of a command. As you might imagine, if you intend for either character to be included in the actual message, you will encounter trouble since they’re… well, delimiters. ADC does this nicely by using escapes if you intend to use specific characters. The workaround for DC++ was to replace those characters with their HTML equivalent. Also, ‘ ‘ (space) is a delimiter for parsing a command. If you intent to include a space in eg a search, the space is converted to a ? (question mark).

While NMDC has no actual specification, it has been agreed upon (by developers) that commands are to be sent case-sensitive. That is, Hello and hellO for the command name isn’t the same. Though there’s no official naming convention, most commands follow CamelCase. Also, there’s no minimum or maximum limit for the length of a command. As I said, there’s no official spec, so if certain hubs / clients object what you’re sending, they aren’t wrong or right. (And you aren’t either.)

Commands are constructed in two parts; It’s name and the actual information. The name is always first and prepended with a $ (of course, since they’re used to denote a new command).

No command in NMDC is extensible without changing the code for the recipient, which is annoying to say the least. This is also why $Supports and the hi-jacking of the description exist.

In NMDC, there are two major parties that interact. Hubs and clients. Each client connect to a hub. The client then proceed, through the hub, to talk and interact with the other clients connected to that same hub. All communication, except strict client to client transfers, are viewable for the hub administrator(s). There’s no native support for security, although extensions (have a look at Valknut) have been made to include eg SSL, though no wide-spread usage exist. Communication in a hub is fully broadcast by and routed through the hub, making the hub a central point in communication between clients; Take down the hub and the clients can’t do anything. (Except download from each other if there’s already a session started.) Clients are identified by their nick (yes, not good).

Each hub is totally separated from another hub; a user in HubA cannot be identified accross the entire network of hubs. Nick is dubious since anyone can change a nick. This means that each can enforce its own rules, and they usually do.

The original NMDC hub didn’t have a configurable port to choose, instead a default existed; port 411. This port is also today considered as the default port. If the port is already in use, the hub would try the next port, 412, and so on. The original NMDC client also didn’t have a configurable port to choose for file transfers; default was port 412. If that one is in use, port 413 is used, and so on.

In the NMDC protocol, it is always the “other party” that speaks first. That is, if you’re a client and connect to a hub, you connect to the socket and the hub says “oh, you want to come in? give me info”. (This is different in ADC where the connecting party speak first.) Connecting to a hub and connecting to another user (to download), there are “mandatory” commands; This mean that unless you provide some of these commands, the hub/client will ignore/kick/disconnect you.

In the early days, when third party clients started arising (such as DC++), Hess changed some of the hub/client response to include a specific lock/key variant to keep out other clients. (Other than his own, that is.) This was in the end also broken, and we still have it today.

File transfers in NMDC are somewhat weird. When e.g. you say you want to download, you say this to the other party. Unfortunately, there can occur a race condition where the other party also want to download from you. In the event of this, the clients picks a random number and tell each other which is the highest. The one with the highest is allowed to download. In DC++, this randomness should of course be somewhat fair. Though, there’s been modifications of DC++ where there were very little “randomness”.

There are three types of users in a hub; a normal user, a registered user and an operator. An operator is usually someone in power, in one way or another. Though, most people might have you believe a person with a key is exclusively an operator; this is wrong. A person with a key is just a registered user who acquired a key for some reason. The registered users are just that; their nickname are registered in the hub and they must supply a password to get in. Normal users are those who didn’t need to input a password and aren’t an operator (they have no power essentially).

NMDC allow for active and passive users. There’s no proxy implemented anywhere in the protocol (or any known hub or client). This mean that a passive user cannot connect to another passive user. So, if you’re passive, you can only connect to those who are active, whereas if you’re active, you can connect to everyone.

There’s essentially three important things in NMDC that users use; chat, transfers and searching. If you didn’t know it before, the most “difficult” thing in NMDC is the actual chat. I’ll get to that in a bit… The underlaying protocol for transfers is TCP; you may have noticed that you need to configure a TCP port to enable transfers. The underlaying protocol for search is UDP; you may have noticed that you need to configure an UDP port to enable searching. A crash course in TCP and UDP; TCP is used for transfers because it will error-check packets (data) when transferring. That is, you truely want everything and don’t want to miss anything. UDP on the other side is used for search because there’s no error-checking for packets. This mean that you’ll get the packets (those you do recieve) faster, and it doesn’t really matter if one or two gets lost. In layman’s terms; think about if you were to “transfer” ten eggs between you and a friend, standing 10 m apart. If you use TCP, you’d take it very carefully and plan the project. It will go ‘slow’, but you’d get what you intended to send. If you use UDP, you’d throw the eggs and don’t care if all ten egg made there safely, as long as “a few of them did”.

So. Chat. Horrible. Horrible, I say. When entering a hub, you and the other clients use a particular encoding for your chat. This encoding is (usually) what your computer is set to. Meaning, if you have (only) installed a Swedish Windows XP, you won’t be able to see e.g. Chinese characters if someone else in the hub has a Chinese Windows XP. This all mean that when you send text, your client think “oh, I hope other people can read this…” Usually, clients, if they don’t know what the character is, will replace the character with an underscore or a question mark or something completely nonsensical. Encodings are basically a way for clients to display text. If you and your friends clients don’t use the same encoding, they won’t be able to display ‘proper’ texts. (Think of this as if you went to a country where you didn’t speak the language. Other people wouldn’t be able to understand you, and you wouldn’t understand them. But if you both speak the same language, say English, you all will understand each other – this is what ADC does.)

Hubs in NMDC can use an identifier; dchub://. This is basically what “http://” is. So, hub addresses can be written in the form of dchub://example.com:411 where 411 is the port. Though, like I said, 411 is already default so you don’t need to specify it if the hub is on that port.

Wow. This became a rather long post. I had intended it to make it into the Wikipedia page, but as soon as I had started, I wasn’t too sure about what to keep and what to discard. Hopefully someone reading this will get enough inspiration.

2 Responses to NMDC: The run down

  1. Pingback: ADC: The run down « DC++: Just These Guys, Ya Know?

  2. Pingback: Protocol chat « DC++: Just These Guys, Ya Know?

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: