Direct Connect uses TCP for client to server communication. The following section describes the format of the Commands, Each field is denoted with < >. The fields in the command are separated by a single space character (ASCII 32). And each Command ends with a | (pipe). All Commands are case sensitive. $Hello

Shortly after a new user, <nick> logs in, the server must send,

  $Hello <nick> 

• <nick> is the nick of a recently logged in user.

This indicates <nick> has logged in. If the new user is an operator, the server must additionally send a $OpList command to all users (documented at $GetNickList).

Each client should add Code Text<nick> to its list of hub users and, if $OpList is also received, update its list of operators. The new client must reply:

  $Version <version>

• <version> is 1.0091 by default.

To obtain a list of other users' nicks, the client may send,

  $GetNickList 

to which the server must reply,

  $NickList <nick1>$$<nick2>$$<nick3>$$...
  $OpList <op1>$$<op2>$$<op3>$$... 

• <nick1>, <nick2>, <nick3>, … compose a $$-separated list of hub users' nicks (including operators). After the final nick there is a $$.
• <op1>$$<op2>$$<op3>$$… is a $$-separated list of connected users that are operators. After the final nick there is a $$. This list is a subset of the $NickList. If there are no connected operators, the server must send ”$OpList ”

If a client receives a $OpList command listing its own nick, it should enable the “Redirect User” and “Kick” functions.

Shortly after logging in, the client must send,

  $MyINFO $ALL <nick> <interest>$ $<speed>$<e-mail>$<sharesize>$ 

• <nick> is the client's nick.
• <interest> is a string describing the user's interest and may be empty (All characters except $ and | are allowed).
• <speed> is a string describing the client's internet connection selected from “56Kbps”, “Satellite”, “DSL”, “Cable”, “LAN(T1)”, and “LAN(T3)” followed by a byte indicating the speed class. The value of the byte is selected from at least 1 for 56Kbps, 3 for cable or DSL, or 7, also for DSL.
• <e-mail> is nick's e-mail address and may be ””.
• <sharesize> is the number of bytes this client shares as a string.

The max size of the description is chosen by the hub implementation. (see $ValidateNick in Client to Server Login) NOTE: some hub implementations do not consider a client to be in a logged in state before it has sent a $MyINFO. this is the correct behaviour, and the NMDC hub is flawed in this respect.

The server must pass this message to all users of the hub, including the sender. The client is expected to send this again if the information changes. SX says that the last byte of the speed is selected from the ascii values of 1 for normal, 2 for away, 3 also for away, 4 for fileserver, 5 also for fileserver, 6 for fileserver away, 7 also for fileserver away, 8 for fireball, 9 also for fireball, 10 for fireball away, and 11 also for fireball away.

To obtain detailed information about a specific user, the client may send,

  $GetINFO <othernick> <nick> 

• <nick> is this sending client's nick.
• <othernick> is the nick of the user that <nick> wants to know about.

The server must respond with exactly the $MyINFO command sent by <othernick> to the server. I don't know what to do if <othernick> has not sent a $MyINFO command (perhaps he would have never been listed in $GetNickList, in which case the command could be rejected). I don't know what to do if <othernick> doesn't exist.

The client may send $ConnectToMe to cause a peer to initiate a peer-to-peer connection for the purpose of transfering data.

  $ConnectToMe <remoteNick> <senderIp>:<senderPort> 

• <senderIp> and <senderPort> are the host and port that the client wishes <remoteNick> to connect to.
• <remoteNick> is the remote user that should initiate the connection.

The server sends this message unaltered to <remotenick>. <remotenick> must open a TCP connection to <senderIp>:<senderPort>.

The client may send this instead of the $ConnectToMe to cause a peer on another hub to initiate a peer-to-peer connection for the purpose of transfering data. This is an extension for multiple hubs, which I'm not worried about yet.

  $MultiConnectToMe <nick> <senderIp>:<senderPort> <linkedserverip>:<linkedserverport> 

A passive client may send this to cause a peer to send a $ConnectToMe back.

  $RevConnectToMe <nick> <remoteNick> 

• <nick> is the sender of the message.
• <remoteNick> is the user which should send to $ConnectToMe.

The server must send this message unmodified to <remoteNick>. If <remoteNick> is an active client, it must send a $ConnectToMe to <nick>. If not, it will reply with $RevConnectToMe. The clients will no longer connect to each other because they are both in passive mode.

The client may send $To to send a private message to a peer.

  $To: <othernick> From: <nick> $<<nick>> <message> 

• <othernick> is the peer who should receive the message.
• <nick> is the sender's nick (both instances).
• <message> is the text of the message (spaces permitted).

The server must pass the message unmodified to client <othernick> which must display the message to the user.

The client may send < > to send a public chat message to all hub users.

  <<nick>> <message> 

• <nick> is this sender's nick.

The server must pass the message unmodified to all other clients including <nick>.

The hub should send $Quit to all users in the hub to let them know the users has disconnected.

  $Quit <nick> 

• <nick> is the sender's nick.

The client must then close the socket. The server must send this message to all users when it is received from a client, or when a client connection is lost. Each client should remove <nick> from its list of hub users.

An op may send a $OpForceMove to cause a client to move to a different server.

  $OpForceMove $Who:<victimNick>$Where:<newIp>$Msg:<reasonMsg> 

• <victimNick> is the nick that will be asked to move.
• <newHub> is the IP address (and optional colon-separated port) of another hub that the user should move to.
• <reasonMsg> is the reason provided to <victimNick>.

On receiving this, the server must send to <victimNick>,

  $ForceMove <newIp>
  $To: <victimNick> From: <senderNick> $<<senderNick>> You are being re-directed to <newHub> because: <reasonMsg> 

• <senderNick> is the nick that sent the $OpForceMove.

In addition to displaying the message, <victimNick> must disconnect from the server and connect to <newIp>. The server should not disconnect the client. I'm not sure if the client should send $Quit or if it should simply close the socket.

Ops may send $Kick to cause the hub to disconnect a user.

  $Kick <victimNick> 

• <victimNick> is the nick of the user to disconnect.

The server must disconnect <victimNick>. The user is notified with the $To command.

Clients are either “active”, indicating they are on the Internet and can receive data directly from peers, or “passive”, in which case they can communicate only through the existing connection to the server. To perform a search, an active client can send,

  $Search <clientip>:<clientport> <searchstring>
  i.e. $Search 64.78.55.32:412 T?T?500000?1?madonna$ray 

• <clientip> is this client's IP address.
• <clientport> is a UDP port on which the client is listening for responses.
• <searchstring> is a string describing the file the client is searching for.

<searchstring> is made up of

  <sizerestricted>?<isminimumsize>?<size>?<datatype>?<searchpattern> 

• <sizerestricted> is T if the search should be restricted to files of a minimum or maximum size, otherwise F.
• <isminimumsize> is F if <sizerestricted> is F or if the size restriction places an upper limit on file size, otherwise T.
• <size> is the minimum or maximum size of the file to report (according to <isminimumsize>) if <sizerestricted> is T, otherwise 0.
• <datatype> restricts the search to files of a particular type. It is an integer selected from:
  • 1 for any file type
  • 2 for audio files (“mp3”, “mp2”, “wav”, “au”, “rm”, “mid”, “sm”)
  • 3 for compressed files (“zip”, “arj”, “rar”, “lzh”, “gz”, “z”, “arc”, “pak”)
  • 4 for documents (“doc”, “txt”, “wri”, “pdf”, “ps”, “tex”)
  • 5 for executables (“pm”, “exe”, “bat”, “com”)
  • 6 for pictures (“gif”, “jpg”, “jpeg”, “bmp”, “pcx”, “png”, “wmf”, “psd”)
  • 7 for video (“mpg”, “mpeg”, “avi”, “asf”, “mov”)
  • 8 for folders
• <searchpattern> is used other users to determine if any files match. It is of the form:

        <term1>$<term2>$<term3>$...$ 

    where ''<term1>'', ''<term2>'', ... are search terms; normally, each search term is a space-delimited word entered by the user. Each search term is followed by a $, and after the last search term there is a total of two $.

The server must forward this message unmodified to all the other users. Every other user with one or more matching files must send one UDP packet to <clientip>:<clientport> for each match containing just the message,

  $SR <nick> <searchresponse> <hubip>:<hubport> 

• <nick> is the nick of the user with the file.
• <hubip>:<hubport> are the values sent in the $Search command.

<searchresponse> is made up of

  <filenamewithpath><filesizeinbytes> <current openslots>/<allopenslots><hubname> 

• <filenamewithpath> is the location of the file on the remote client.
• <filesizeinbytes> is the size of the file found.
• <current openslots> is the number of free slots the remote client has available.
• <allopenslots> is the total number of slots the remote client has available.
• “” is the ascii character 5.

Note: When the client sends the $SR command to the server it adds <ClientsNick> to the end of <searchresponse>.

To search the network for files matching a search term, a passive client may send,

  $Search Hub:<searchingNick> <searchstring> 

The server must forward this message unmodified to all the other users. Every other user with one or more matching files must send to the server,

  $SR <resultNick> <filepath><filesize> <freeslots>/<totalslots><hubname> (<hubhost>[:<hubport>])^E<searchingNick> 

• <resultNick> is the nick of the user reporting the result.
• <filepath> is the path and file name of the matching file on <resultNick>'s computer. Eventually, <searchingNick> will pass this string unmodified to <resultNick> to download the file.
• <filesize> is the integer size of the file in bytes.
• <freeslots> and <totalslots> is <resultNick>'s number of free slots and total slots, respectively.
• <hubname> is the name of the hub from which the query arrived.
• <hubhost> and <hubport> are the hostname and port of the hub as perceived by <resultNick> (if :<hubport> is omitted, it is taken to be 411).
• <searchingNick> is the nick that initiated the search and is the same as in the $Search command.
•  is the ascii character 5.

The server must pass the $SR message unmodified to <searchingNick>.

This is takes the same parameters as $Search (both active and passive) and behaves exactly as $Search, except the hub must additionally pass the search request to the other hubs in the cluster using the hub-to-hub $Search command.

Replies to passive search requests are sent through the server. Compare the $SR in Command Types (client to client).

  $SR <replynick> <searchresponse><searchnick> 

• <replynick> is the nick of the user with the file.
• <searchnick> is the nick of the user who did the query.
•  is the ascii character 5.

<searchresponse> is made up of

  <filenamewithpath><filesizeinbytes> <current openslots>/<allopenslots><hubname> (<hubip>) 

• <filenamewithpath> is the location of the file on the remote client.
• <filesizeinbytes> is the size of the file found.
• <current openslots> is the number of free slots the remote client has available.
• <allopenslots> is the total number of slots the remote client has available.
• <hubname> is the name of the hub on which the respondent recieved the passive search request.
• <hubip> is the IP address of the hub. Note that is does not have a port number (at least DC++ does not send one).
•  is the ascii character 5.

The search result should be forwarded to <searchnick>, but without the <searchnick> at the end.