diff options
author | irungentoo <irungentoo@gmail.com> | 2014-03-11 20:01:52 -0400 |
---|---|---|
committer | irungentoo <irungentoo@gmail.com> | 2014-03-11 20:01:52 -0400 |
commit | 128a0d24446f4d1b5071795742e81e17a9e73fd5 (patch) | |
tree | 4c56cc7273f9282bf36680947af9863556f572ec | |
parent | 500528a93f32000204a3b3cfceaec84492a8a400 (diff) |
Detailed docs for TCP server pretty much done.
Implementation coming soon.
-rw-r--r-- | docs/TCP_Network.txt | 106 | ||||
-rw-r--r-- | toxcore/tox.h | 1 |
2 files changed, 100 insertions, 7 deletions
diff --git a/docs/TCP_Network.txt b/docs/TCP_Network.txt index b1059892..b9215943 100644 --- a/docs/TCP_Network.txt +++ b/docs/TCP_Network.txt | |||
@@ -10,12 +10,12 @@ probably not take a huge toll on the network and will assure that people | |||
10 | can use Tox regardless of the quality of their internet connection. | 10 | can use Tox regardless of the quality of their internet connection. |
11 | 11 | ||
12 | 12 | ||
13 | How it's probably going to work: | 13 | How it's going to work: |
14 | 1. Alice, a Tox client on a TCP only network generates a temporary public key | 14 | 1. Alice, a Tox client on a TCP only network generates a temporary public key |
15 | and connects to a bootstrap node. | 15 | and connects to a bootstrap node. |
16 | 16 | ||
17 | 2. Using the bootstrap node she finds and connects to a (exact number to be | 17 | 2. Using the bootstrap node she finds and connects to a couple (exact number |
18 | determined later) number of random nodes that have TCP relay support. | 18 | to be determined later) number of random nodes that have TCP relay support. |
19 | 19 | ||
20 | 3. She uses the onion through the TCP relay connections to send friend requests | 20 | 3. She uses the onion through the TCP relay connections to send friend requests |
21 | or tell online friends which TCP nodes she is connected to and her temporary | 21 | 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. | |||
28 | 5. That connection is used by both to transmit encrypted Messenger and A/V | 28 | 5. That connection is used by both to transmit encrypted Messenger and A/V |
29 | packets. | 29 | packets. |
30 | 30 | ||
31 | 6. If one of the nodes shuts down while it is routing traffic, Alice and Bob | 31 | 6. If one of the nodes shuts down while it is currently routing traffic, Alice |
32 | just switch to one of the other nodes to which they are both connected. | 32 | and bob just switch to one of the other nodes they are both connected to. |
33 | 33 | ||
34 | 34 | ||
35 | Actual implementation details coming soon. | 35 | Detailed implementation details: |
36 | |||
37 | There are two distinct parts for TCP relays, the client part and the server | ||
38 | part. | ||
39 | |||
40 | The server acts as the actual relay. Servers must have fully forwarded TCP | ||
41 | ports (NAT-PMP and uPNP can help here). The first port the server will try | ||
42 | binding to is 443 followed by port 3389 and possibly some others. Onion packets | ||
43 | can be sent/received through the TCP servers. | ||
44 | |||
45 | |||
46 | Server: | ||
47 | |||
48 | The public/private key pair the TCP server uses is the same one he uses for the | ||
49 | DHT. | ||
50 | |||
51 | all crypto for communication with the server uses the crypto_box() function of | ||
52 | NaCl. | ||
53 | |||
54 | TCP doesn't have packets so what we will refer to as packets are sent this way: | ||
55 | [[uint16_t (length of data)][data]] | ||
56 | |||
57 | So if you would inspect the TCP stream you would see: | ||
58 | [[uint16_t (length of data)][data]][[uint16_t (length of | ||
59 | data)][data]][[uint16_t (length of data)][data]] | ||
60 | |||
61 | When the client connects to the server, he sends this packet: | ||
62 | [public key of client (32 bytes)][nonce for the encrypted data [24 | ||
63 | bytes]][encrypted with the private key of the client and public key of the | ||
64 | server and the nonce:[public key (32 bytes) and][base nonce we want the server | ||
65 | to use to encrypt the packets sent to us (24 bytes)]] | ||
66 | |||
67 | The server responds with: | ||
68 | [nonce for the encrypted data [24 bytes]][encrypted with the public key of the | ||
69 | client and private key of the server and the nonce:[public key (32 bytes) | ||
70 | and][base nonce we want the client to use to encrypt the packets sent to us (24 | ||
71 | bytes)]] | ||
72 | |||
73 | All packets to the server are end to end encrypted with the information | ||
74 | received | ||
75 | (and sent) in the handshake. | ||
76 | |||
77 | (first packet is encrypted with the base nonce the private key for which the | ||
78 | client sent the server the public key and the public key we sent to the client, | ||
79 | the next with base nonce + 1...) | ||
80 | |||
81 | |||
82 | each packet sent to/from the server has an id (the first byte of the plain text | ||
83 | data of the packet.) | ||
84 | |||
85 | ids 0 to 15 are reserved for special packets, ids 16 to 255 are used to denote | ||
86 | who we want the data to be routed to/who the packet is from. | ||
87 | |||
88 | special ids and packets: | ||
89 | 0 - Routing request. | ||
90 | [uint8_t id (0)][public key (32 bytes)] | ||
91 | 1 - Routing request response. | ||
92 | [uint8_t id (1)][uint8_t (rpid) 0 if refused, packet id if accepted][public key | ||
93 | (32 bytes)] | ||
94 | 2 - Connect notification: | ||
95 | [uint8_t id (2)][uint8_t (packet id of connection that got connected)] | ||
96 | 3 - Disconnect notification: | ||
97 | [uint8_t id (3)][uint8_t (packet id of connection that got disconnected)] | ||
98 | 8 - onion packet (same format as initial onion packet (See: Prevent | ||
99 | tracking.txt) but packet id is 8 instead of 128) | ||
100 | 9 - onion packet response (same format as onion packet with id 142 but id is 9 | ||
101 | instead.) | ||
102 | |||
103 | The rest of the special ids are reserved for possible future usage. | ||
104 | |||
105 | If the server receives a routing request he stores server side that the client | ||
106 | wants to connect to the person with that public key and sends back a Routing | ||
107 | request response with the rpid along with the public key sent in the request. | ||
108 | |||
109 | If for some reason the server must refuse the routing request (too many) he | ||
110 | sends the response with a rpid of 0. | ||
111 | |||
112 | If the person who the client wants to connect to is also online and wants to | ||
113 | connect to the client a connect notification is sent to both with the | ||
114 | appropriate packet id. | ||
115 | |||
116 | If either one disconnects, a disconnect notification is sent to the other with | ||
117 | appropriate packet id. | ||
118 | |||
119 | If a client sends a disconnect notification, the entry on the server for that | ||
120 | routed connection is cleared and a disconnect notification is sent to the peer | ||
121 | (if he was online) | ||
122 | |||
123 | If the server receives an onion packet he handles it the same as he would if it | ||
124 | was one received normally via UDP, he must also assure himself that any | ||
125 | responses must be sent to the proper client. | ||
126 | |||
127 | Client: | ||
128 | |||
129 | Implementation details coming soon. | ||
diff --git a/toxcore/tox.h b/toxcore/tox.h index 1db5c46e..3dee2b6e 100644 --- a/toxcore/tox.h +++ b/toxcore/tox.h | |||
@@ -250,7 +250,6 @@ uint16_t tox_get_self_name(Tox *tox, uint8_t *name, uint16_t nlen); | |||
250 | int tox_get_name(Tox *tox, int friendnumber, uint8_t *name); | 250 | int tox_get_name(Tox *tox, int friendnumber, uint8_t *name); |
251 | 251 | ||
252 | /* Set our user status. | 252 | /* Set our user status. |
253 | * You are responsible for freeing status after. | ||
254 | * | 253 | * |
255 | * returns 0 on success. | 254 | * returns 0 on success. |
256 | * returns -1 on failure. | 255 | * returns -1 on failure. |