Detailed docs for TCP server pretty much done.

Implementation coming soon.

docs/TCP_Network.txt

@@ -10,12 +10,12 @@ probably not take a huge toll on the network and will assure that people
 can use Tox regardless of the quality of their internet connection.
 
 
-How it's probably going to work:
+How it's going to work:
 1. Alice, a Tox client on a TCP only network generates a temporary public key 
 and connects to a bootstrap node.
 
-2. Using the bootstrap node she finds and connects to a (exact number to be 
-determined later) number of random nodes that have TCP relay support.
+2. Using the bootstrap node she finds and connects to a couple (exact number 
+to be determined later) number of random nodes that have TCP relay support.
 
 3. She uses the onion through the TCP relay connections to send friend requests 
 or tell online friends which TCP nodes she is connected to and her temporary 
@@ -28,8 +28,102 @@ with alice using that temporary public key.
 5. That connection is used by both to transmit encrypted Messenger and A/V 
 packets.
 
-6. If one of the nodes shuts down while it is routing traffic, Alice and Bob 
-just switch to one of the other nodes to which they are both connected.
+6. If one of the nodes shuts down while it is currently routing traffic, Alice 
+and bob just switch to one of the other nodes they are both connected to.
 
 
-Actual implementation details coming soon.
+Detailed implementation details:
+
+There are two distinct parts for TCP relays, the client part and the server 
+part.
+
+The server acts as the actual relay. Servers must have fully forwarded TCP 
+ports (NAT-PMP and uPNP can help here). The first port the server will try 
+binding to is 443 followed by port 3389 and possibly some others. Onion packets 
+can be sent/received through the TCP servers.
+
+
+Server:
+
+The public/private key pair the TCP server uses is the same one he uses for the 
+DHT. 
+
+all crypto for communication with the server uses the crypto_box() function of 
+NaCl.
+
+TCP doesn't have packets so what we will refer to as packets are sent this way: 
+[[uint16_t (length of data)][data]]
+
+So if you would inspect the TCP stream you would see:
+[[uint16_t (length of data)][data]][[uint16_t (length of 
+data)][data]][[uint16_t (length of data)][data]]
+
+When the client connects to the server, he sends this packet:
+[public key of client (32 bytes)][nonce for the encrypted data [24 
+bytes]][encrypted with the private key of the client and public key of the 
+server and the nonce:[public key (32 bytes) and][base nonce we want the server 
+to use to encrypt the packets sent to us (24 bytes)]]
+
+The server responds with:
+[nonce for the encrypted data [24 bytes]][encrypted with the public key of the 
+client and private key of the server and the nonce:[public key (32 bytes) 
+and][base nonce we want the client to use to encrypt the packets sent to us (24 
+bytes)]]
+
+All packets to the server are end to end encrypted with the information 
+received 
+(and sent) in the handshake.
+
+(first packet is encrypted with the base nonce the private key for which the 
+client sent the server the public key and the public key we sent to the client, 
+the next with base nonce + 1...)
+
+
+each packet sent to/from the server has an id (the first byte of the plain text 
+data of the packet.)
+
+ids 0 to 15 are reserved for special packets, ids 16 to 255 are used to denote 
+who we want the data to be routed to/who the packet is from.
+
+special ids and packets:
+0 - Routing request.
+[uint8_t id (0)][public key (32 bytes)]
+1 - Routing request response.
+[uint8_t id (1)][uint8_t (rpid) 0 if refused, packet id if accepted][public key 
+(32 bytes)]
+2 - Connect notification:
+[uint8_t id (2)][uint8_t (packet id of connection that got connected)]
+3 - Disconnect notification:
+[uint8_t id (3)][uint8_t (packet id of connection that got disconnected)]
+8 - onion packet (same format as initial onion packet (See: Prevent 
+tracking.txt) but packet id is 8 instead of 128)
+9 - onion packet response (same format as onion packet with id 142 but id is 9 
+instead.)
+
+The rest of the special ids are reserved for possible future usage.
+
+If the server receives a routing request he stores server side that the client 
+wants to connect to the person with that public key and sends back a Routing 
+request response with the rpid along with the public key sent in the request.
+
+If for some reason the server must refuse the routing request (too many) he 
+sends the response with a rpid of 0.
+
+If the person who the client wants to connect to is also online and wants to 
+connect to the client a connect notification is sent to both with the 
+appropriate packet id.
+
+If either one disconnects, a disconnect notification is sent to the other with 
+appropriate packet id.
+
+If a client sends a disconnect notification, the entry on the server for that 
+routed connection is cleared and a disconnect notification is sent to the peer 
+(if he was online)
+
+If the server receives an onion packet he handles it the same as he would if it 
+was one received normally via UDP, he must also assure himself that any 
+responses must be sent to the proper client.
+
+Client:
+
+Implementation details coming soon.

toxcore/tox.h

@@ -250,7 +250,6 @@ uint16_t tox_get_self_name(Tox *tox, uint8_t *name, uint16_t nlen);
 int tox_get_name(Tox *tox, int friendnumber, uint8_t *name);
 
 /* Set our user status.
- * You are responsible for freeing status after.
  *
  *  returns 0 on success.
  *  returns -1 on failure.