Why the NMDC protocol is terrible

I don’t like the NMDC protocol. I’m sure you’ve noticed that by now. So, in this post I intend to “document” the things that make people shrug when they think of the protocol NMDC. Note that what I’m about to say has no direct correlation to ADC, or that I’m implying that the issues I speak of are somehow fixed.

Now go read the previous sentence again before I begin.

* There is absolutely no protocol specification. Developers need to guess what everyone is sending, because we have no actual way of knowing which implemented solution is the best.
* The protocol was written to support a (relatively small) proprietary client and hub system. Thus, it has both remnants from a time when Jonathan Hess (the author of NMDC) wanted to exclude third-party hubs and clients and when the network was very small, compared to now.
* The lack of a native queing system. In NMDC, when one try to download, one must have the good luck of trying to connect while the other party has a slot open. Since there’s no queing system, everyone is up for grabs; And the people that have been waiting the longest may wait even longer.
* When trying to download from someone, both parties negotiate a “download number”. The one that has the highest number is allowed to download. This mean that if two people are trying to connect to each other, the one with the “cheating client that always claim a very high value” will get to download first.
* While this may seem pety and a non-issue… There are actual commands in the protocol that are spelled incorrectly. Sure, semantic, but still. Darn ugly.
* No native text encoding is enforced on clients.
* There is no security in terms of TLS or similar. (Valknut is the only client I know which has had semi-security in this department. But I haven’t seen anything that resembles a ‘specification’ concerning the extended TLS/SSL functionality.)
* File names is still a central part of file sharing, while this is utterly flawed, which we’ve seen with TTH.
* As the original client didn’t allow for multiple hubs, or the fact that the system wasn’t intended for third-party applications, the tag has been forced upon our description.
* The utter and complete lack of point concerning Locks and Keys in NMDC. It’s a security prevention that prevents nothing at this point. (And also, the fact that certain commands are quite pointless to begin with.)
* No global (or quasi-global) user identification. Everyone is identified by their nicks.
* There is no way to tell one search from another.
* If a client developer want to add a new feature/command to the protocol, other hubs and clients will need to change to support it (or even allow the client to function at all.)

These are the things that spring to mind right now. Anything else that’s just plain awful that I didn’t mentioned?

(In NMDC, the connecting party doesn’t speak first, which I find a little odd. However, it’s nothing I consider “bad”. It’s just odd for me since I’m so used to ADC.)

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”