DirectConnect TNG

A call for a new protocol

1.0 Introduction

1.1 Background

These are all working solutions, but keeping this strategy will ultimately make the system unnecessary complex and finally break compatibility with the Neo-Modus clients.

1.2 Status of this document

Please discuss this with me and others if you have suggestions or questions.

1.3 The dark side of Direct Connect

• The protocol doesn't handle error conditions (If something went wrong, just ignore it, thats the implementation).
• Implementations doesn't handle different states of the protocol, command scopes and order is undefined in most cases and implemented differently between projects. *
• The whole network relies on a simple nickname, this is problematic when somebody has taken your name, or if you use the same nickname from different computers, or if someone uses a different nickname on different hubs (thus you are unable to download).
• Searches are difficult to track (which search result belongs to which search request). This makes automated searches difficult.
• No implementation of hashes to uniquely identify files.
• The default ports are 411 and 412 which are privileged ports on Unix and commonly blocked by firewalls. *
• The protocol doesn't support multisource downloads (correlated with file hashing)
• The protocol doesn't natively support secure communication (plain text passwords etc)
• The protocol doesn't support IPv6
• Hubs aren't uniquely identified.
• The Client-Client protocol is uneccesary complex, with many interactions, which gives significant delays before transfers.
• No native support for multiple hubs.
• MultiSearch and MultiConnectToMe should be handled transparently by hubs. *
• The protocol doesn't escape special characters, like: |, $, <, >, character 0x5 or even spaces in some cases
• No unicode support.
• Hubs should probe and disconnect ineffective connections (with large send queues and slow response) *
• No way to protect your shares from outsiders (i.e. RIAA scanning your network without being on the same hub as you).

1.4 A proposed solution

Instead of adding bloat to the current protocol, which seems to be the trend these days, I propose creating a totally new system around on the DC model (clients and hubs), which should be reasonable easy to implement in current open source DC clients.
In short, this means a brand new protocol, which addresses most of the annoying parts in the current Direct Connect protocol.
Note: not all the flaws in the protocol is addressed in this draft.

1.5 Executive summary

In general we remove the nickname dependencies, add hashes, support full unicode and make a more statefull and secure protocol. For the client-client protocol we are moving towards a (semi-)stateless protocol and add the option to deny connections for "outsiders".

1.6 Thanks to

2.0 Language and standards

2.1 Messaging

Commands are (unlike the current DC protocol) transmitted as lines separated by the common Internet standard; CRLF (carriage return and linefeed), which means it's easier to debug implementations using a telnet session. Special characters needs to be escaped using C-style backslashes.

The lock/key challenge response system is gone.

The connecting party (client) will always talk first when connected (this to make automated scans difficult).

All error/info strings from special commands should not exceed 50 bytes.

2.2 Address notation

The addresses should be on this format:

• IPv4: "n.n.n.n:port"
• IPv6: "[x:x:x:x:x:x:x:x]:port" (follows the RFC 2732 guidelines).
• DNS: "fully.qualified.hostname:port (Note: The DNS name must match your reverse DNS for security reasons)."

2.3 New concepts

The GUID is calculated as a SHA-1 (160 bit) hash of the address notation "ip:port" and a timestamp (IPv4 or IPv6 doesn't really matter). This GUID is usually represented as a 40 byte text string hexadecimal style, but that might be too large. It is possible to "squeeze" this size by using some other encoding (20 bytes is minimum nevertheless).

The GUID is created the first time the client is ran, and it will be stored and used for each later session. The user will be identified by this ID across different hubs and names. All login systems (registered users, etc) will use the GUID to identify a user.

Another new concept is "channels", similar to to IRC-channels or "a chat room". The reason for this is to ease the bandwidth load for userinfo, since the GUID would otherwise generate alot of traffic. After connecting to a hub a user may join several channels (limited by the server). The user will only receive userinfo for the users on those channels.

Unlike IRC the channels are not generated ad-hoc, meaning the server admin has to setup the channels. An operator is operator for all channels.

2.4 New server functionality

The server has enhanced flow control mechanisms. For example a hub can send a "Ping" requesting a "Pong" from each client to determine wether the host is responding within a reasonable amount of time or not. If it isn't it should be disconnected.
Also the hub can disconnect clients if they are message "flooding", or if their send queue is filling up. The search commands can optinally by the hub be sent to linked hubs, but they may just aswell be discarded if the hub is reaching some bandwidth, memory or CPU usage limit.

3.0 Command reference