diff options
author | irungentoo <irungentoo@gmail.com> | 2013-07-18 13:45:28 -0400 |
---|---|---|
committer | irungentoo <irungentoo@gmail.com> | 2013-07-18 13:45:28 -0400 |
commit | 7611ca810f9af9f0f534a85869cd36e35137ec6f (patch) | |
tree | 59203d76f94be2e265597e440d088f988c73faad /docs | |
parent | ad44110fd54d5e0400f6f6749922e1c788d04f7d (diff) |
Added draft of routing protocol.
Diffstat (limited to 'docs')
-rw-r--r-- | docs/Routing.txt | 66 |
1 files changed, 66 insertions, 0 deletions
diff --git a/docs/Routing.txt b/docs/Routing.txt new file mode 100644 index 00000000..7548f029 --- /dev/null +++ b/docs/Routing.txt | |||
@@ -0,0 +1,66 @@ | |||
1 | Routing Protocol. | ||
2 | |||
3 | The routing protocol will only be used when two clients have difficulty | ||
4 | connecting to each other. This is usually because of NAT issues. For example, | ||
5 | two people who are behind symmetric NATs are not capable of connecting to each | ||
6 | other directly. | ||
7 | |||
8 | The routing protocol severely limits the speed at which two clients can | ||
9 | communicate. This is so that the user of the software does not feel the need to | ||
10 | turn it off because it is taking too much bandwidth and to prevent peers from | ||
11 | using it without good reason. | ||
12 | |||
13 | The routing protocol does not provide any anonymity, only convenience. | ||
14 | |||
15 | ############# | ||
16 | |||
17 | Draft of protocol: | ||
18 | |||
19 | Alice wants to connect to Bob. | ||
20 | |||
21 | Alice queries the DHT and manages to obtain the ip_port of Bob from Carol and | ||
22 | Dan both of who are closest mathematically to Bob in the DHT. | ||
23 | |||
24 | Unfortunately Alice is enable to connect to the ip_port for Bob provided by | ||
25 | Carol and Dan. | ||
26 | |||
27 | Alice assumes then that Bob is behind a bad NAT. | ||
28 | |||
29 | Alice therefore randomly picks between Carol and Dan. She picks Carol. | ||
30 | |||
31 | Alice connects to Carol using the Lossless UDP protocol. | ||
32 | |||
33 | She then sends a routing request over the connection: | ||
34 | |||
35 | [char with a value of 16][Public key of who to route the packets to(client_id) | ||
36 | (32 bytes)] | ||
37 | |||
38 | Carol checks if she is connected via the DHT to the person (Bob) who the public | ||
39 | key appears in the routing request. | ||
40 | |||
41 | If she is not she kills the connection. | ||
42 | |||
43 | If she is, she waits for the next data packet to arrive from Alice. | ||
44 | |||
45 | As soon as she receives it she connects to the person (Bob) and sends it to him. | ||
46 | |||
47 | If nothing is received from Bob within a timeout, the connection is killed. | ||
48 | |||
49 | If something is received from Bob, it is sent to Alice and the connection is | ||
50 | confirmed and continues until either Bob or Alice disconnect. | ||
51 | |||
52 | ############# | ||
53 | |||
54 | Some notes: | ||
55 | |||
56 | If both Alice and Bob are friends they will create two different connections | ||
57 | when each try to connect to each other witch is good because it means data can | ||
58 | be sent/received on both which lower the chances of the connection being | ||
59 | severed because the node shut itself down or data being lost because of a bad | ||
60 | node. It however doubles the amount of data we send/receive. | ||
61 | |||
62 | If both peers manage to connect to each other, the routing connection is | ||
63 | killed. | ||
64 | |||
65 | All data transmitted trough this protocol must be encrypted in a way that it is | ||
66 | only decryptable by the receiver and only the receiver. | ||