Client to Server Login

When first logging in, the client creates a socket connection. The server sends,

$Lock <lock> Pk=<pk>
$HubName <hubname>

• <lock> is used to generate <key>
  See Appendix A: Converting a Lock into a Key for how to compute the key from the lock.
• <pk> is unused, but SG believes Pk stands for "private" or "public key".
• <hubname> is the name of the hub your connecting to (spaces permitted).

The client must then respond with,

$Key <key>
$ValidateNick <nick>

• <key> is computed as above.
• <nick> is the user's username.
All characters except $ and | and space are allowed (the NMDC server converts any spaces to underscores and allows the login to proceed using the corrected username).

If <nick> is already in use or is otherwise not accepted, the server must send,

$ValidateDenide

It really is $ValidateDenide, not $ValidateDenied. In this case, the client must send $ValidateNick again. Otherwise, the nick is accepted. The server may then send,

$GetPass

to which the client must reply,

$MyPass <password>

• <password> is the plain-text password for <nick>.

If the password is accepted and the user is an Op, the server must send,

$LogedIn

$BadPass

and close the connection. NMDC hub answers with $HubIsFull even before the nickname is sent. Other hub implementations usually wait until the nickname is validated and then decide whether to let the user in or to disconnect him.
If no password is required or the server accepts the password, the server must finally send,

$Hello <nick>

• <nick> the clients nickname.

The user is now logged in.

Download Example:

	Client <-> Server Communication in DC. 01-26-2003. By Sid
	---------------------------------------------------------- 

	Client Hub Login Example
	---------------------- 
	C = client
	H = hub 

	C>H: Connection
	H>C: $Lock <lock> Pk=<pk>|
	H>C: $HubName <hubname>|
	C>H: $Key <key>|$ValidateNick <nick>|
	C>H: $MyINFO $ALL <nick> <interest>$ $<speed>$<e-mail>$<sharesize>$
	C>H: $GetINFO <othernick> <nick>
	C>H: $GetINFO...