summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat
-rw-r--r--README.md92
-rw-r--r--core/DHT.c4
-rw-r--r--docs/DHT.txt87
-rw-r--r--docs/TODO.txt25
4 files changed, 121 insertions, 87 deletions
diff --git a/README.md b/README.md
index 2d35090c..a5de88ef 100644
--- a/README.md
+++ b/README.md
@@ -11,7 +11,7 @@ Proposal of a free as in freedom skype replacement:
11 11
12 -UDP most be used for everything simply because you can't do hole punching with TCP (well you can but it doesn't work all the time) 12 -UDP most be used for everything simply because you can't do hole punching with TCP (well you can but it doesn't work all the time)
13 13
14 -Every peer is represented as a byte string (the client id) (it is the hash (SHA-256 ?) of the public key of the peer). (if you want to add someone you need that id.) 14 -Every peer is represented as a byte string (the client id) (it is the hash (SHA-256 ?) of the public key of the peer). (if you want to add someone you need that id (either ask that person directly or maybe through some kind of search engine?))
15 15
16 -Use something torrent DHT style so that peers can find the ip of the other peers when they have their id. 16 -Use something torrent DHT style so that peers can find the ip of the other peers when they have their id.
17 17
@@ -32,6 +32,10 @@ Proposal of a free as in freedom skype replacement:
32 5.Reliable sending of data larger than the maximum packet size. 32 5.Reliable sending of data larger than the maximum packet size.
33 ... 33 ...
34 34
35-------TODO-------:
36
37 See: docs/TODO.txt
38
35-------Important-stuff--: 39-------Important-stuff--:
36 40
37 Use the same UDP socket for everything 41 Use the same UDP socket for everything
@@ -39,90 +43,6 @@ Proposal of a free as in freedom skype replacement:
39-------Details---------: 43-------Details---------:
40 44
41 DHT protocol: 45 DHT protocol:
42 Follows pretty much the principle of the torrent DHT: http://www.bittorrent.org/beps/bep_0005.html (READ IT) 46 see: docs/DHT.txt
43
44 But:
45 Vastly simplified packet format.
46
47 Boostrapping:
48 The first time you install the client we bootstrap it with a node on our servers.(bandwidth should not be a problem as the client only needs to be sent one reply.)
49
50
51 Basics (All the numbers here are just guesses and are probably not optimal values):
52
53 client list: A list of node ids closest (mathematically see bittorrent doc) to ours matched with ip addresses + port number corresponding to that id and a timestamp containing the time or time since the client was successfully pinged.
54
55 "friends" list: A list containing the node_ids of all our "friends" or clients we want to connect to.
56 Also contains the ip addresses + port + node_ids + timestamp(of last ping like in the client list) of the 8 clients closest (mathematically see bittorrent doc) to each "friend"
57
58 Two pinged lists:
59 -One for storing a list of ips along with their ping_ids and a timestamp for the ping requests
60 -One for storing a list of ips along with their ping_ids and a timestamp for the get nodes requests
61 Entries in the pinged lists expire after 5 seconds.
62 If one of the lists becomes full, the expire rate reduces itself one second or the new ping takes the place of the oldest one.
63
64
65 Entries in client list and "friends" list expire after 300 seconds without ping response.
66 Each client stores a maximum of 32 entries in its client list.
67 Each client in the client list and "friends" list is pinged every 60 seconds.
68 Each client in the client list and "friends" list has a timestamp which denote the last time it was successfully pinged.
69 If the corresponding clients timestamp is more than 130 seconds old it is considered bad.
70 Send a get nodes request every 20 seconds to a random good node for each "friend" in our "friends" list.
71 Send a get nodes request every 20 seconds to a random good node in the client list.
72
73
74 When a client receives any request from another:
75 -Respond to the request
76 -Ping request is replied to with with a ping response containing the same ping_id
77 -Get nodes request is replied with a send nodes reply containing the same ping_id and the good nodes from the client list and/or the "friends" list that are closest to the requested_node_id
78
79 -If the requesting client is not in the client list:
80 -If there are no bad clients in the list and the list is full:
81 -If the id of the other client is closer (mathematically see bittorrent doc) than at least one of the clients in the list or our "friends" list:
82 -Send a ping request to the client.
83 -if not forget about the client.
84
85 -If there are bad clients and/or the list isn't full:
86 -Send a ping request to the client
87
88 When a client receives a response:
89 -Ping response
90 -If the node was previously pinged with a matching ping_id (check in the corresponding pinged list.)
91 -If the node is in the client list the matching client's timestamp is set to current time.
92 -If the node is in the "friends" list the matching client's timestamp is set to current time for every occurrence.
93 -If the node is not in the client list:
94 -If the list isn't full, add it to the list.
95 -If the list is full, the furthest away (mathematically see bittorrent doc) bad client is replaced by the new one.
96 -If the list is filled with good nodes replace the furthest client with it only if it is closer than the replaced node.
97 -for each friend in the "friends" list:
98 -If that friend's client list isn't full, add that client to it
99 -If that friend's client list contains bad clients, replace the furthest one with that client.
100 -If that friend's client list contains only good clients
101 -If the client is closer to the friend than one of the other clients, it replaces the farthest one
102 -If not, nothing happens.
103
104 -Send nodes
105 -If the ping_id matches what we sent previously (check in the corresponding pinged list.):
106 -Each node in the response is pinged.
107
108
109
110
111
112 Protocol:
113
114 Node format: [char array (node_id), length=32 bytes][ip (in network byte order), length=4 bytes][port (in network byte order), length=2 bytes][Padding , length=2 bytes]
115
116 Valid queries and Responses:
117
118 Ping(Request and response): [byte with value: 00 for request, 01 for response][random 4 byte (ping_id)][char array (client node_id), length=32 bytes]
119 ping_id = a random integer, the response must contain the exact same number as the request
120
121
122 Get nodes (Request):
123 Packet contents: [byte with value: 02][random 4 byte (ping_id)][char array (client node_id), length=32 bytes][char array: requested_node_id (node_id of which we want the ip), length=32 bytes]
124 Valid replies: a send_nodes packet
125 47
126 Send_nodes (response): [byte with value: 03][random 4 byte (ping_id)][char array (client node_id), length=32 bytes][Nodes in node format, length=40 * (number of nodes (maximum of 8 nodes)) bytes]
127 ex: 03[Node][Node][Node]
128 48
diff --git a/core/DHT.c b/core/DHT.c
index 547520d2..ef04a391 100644
--- a/core/DHT.c
+++ b/core/DHT.c
@@ -15,14 +15,16 @@ int sendpacket(IP_Port ip_port, char * data, uint32_t length)
15//Function to recieve data, ip and port of sender is put into ip_port 15//Function to recieve data, ip and port of sender is put into ip_port
16//the packet data into data 16//the packet data into data
17//the packet length into length. 17//the packet length into length.
18//dump all empty packets.
18int recievepacket(IP_Port * ip_port, char * data, uint32_t * length) 19int recievepacket(IP_Port * ip_port, char * data, uint32_t * length)
19{ 20{
20 ADDR addr; 21 ADDR addr;
21 uint32_t addrlen = sizeof(addr); 22 uint32_t addrlen = sizeof(addr);
22 (*(int *)length) = recvfrom(sock, data, MAX_UDP_PACKET_SIZE, 0, (struct sockaddr *)&addr, &addrlen); 23 (*(int *)length) = recvfrom(sock, data, MAX_UDP_PACKET_SIZE, 0, (struct sockaddr *)&addr, &addrlen);
23 if(*(int *)length == -1) 24 if(*(int *)length <= 0)
24 { 25 {
25 //nothing recieved 26 //nothing recieved
27 //or empty packet
26 return -1; 28 return -1;
27 } 29 }
28 ip_port->ip = addr.ip; 30 ip_port->ip = addr.ip;
diff --git a/docs/DHT.txt b/docs/DHT.txt
new file mode 100644
index 00000000..486aa38c
--- /dev/null
+++ b/docs/DHT.txt
@@ -0,0 +1,87 @@
1DHT protocol:
2 Follows pretty much the principle of the torrent DHT: http://www.bittorrent.org/beps/bep_0005.html (READ IT)
3
4 But:
5 Vastly simplified packet format.
6
7 Boostrapping:
8 The first time you install the client we bootstrap it with a node on our servers.(bandwidth should not be a problem as the client only needs to be sent one reply.)
9
10
11 Basics (All the numbers here are just guesses and are probably not optimal values):
12
13 client list: A list of node ids closest (mathematically see bittorrent doc) to ours matched with ip addresses + port number corresponding to that id and a timestamp containing the time or time since the client was successfully pinged.
14
15 "friends" list: A list containing the node_ids of all our "friends" or clients we want to connect to.
16 Also contains the ip addresses + port + node_ids + timestamp(of last ping like in the client list) of the 8 clients closest (mathematically see bittorrent doc) to each "friend"
17
18 Two pinged lists:
19 -One for storing a list of ips along with their ping_ids and a timestamp for the ping requests
20 -One for storing a list of ips along with their ping_ids and a timestamp for the get nodes requests
21 Entries in the pinged lists expire after 5 seconds.
22 If one of the lists becomes full, the expire rate reduces itself one second or the new ping takes the place of the oldest one.
23
24
25 Entries in client list and "friends" list expire after 300 seconds without ping response.
26 Each client stores a maximum of 32 entries in its client list.
27 Each client in the client list and "friends" list is pinged every 60 seconds.
28 Each client in the client list and "friends" list has a timestamp which denote the last time it was successfully pinged.
29 If the corresponding clients timestamp is more than 130 seconds old it is considered bad.
30 Send a get nodes request every 20 seconds to a random good node for each "friend" in our "friends" list.
31 Send a get nodes request every 20 seconds to a random good node in the client list.
32
33
34 When a client receives any request from another:
35 -Respond to the request
36 -Ping request is replied to with with a ping response containing the same ping_id
37 -Get nodes request is replied with a send nodes reply containing the same ping_id and the good nodes from the client list and/or the "friends" list that are closest to the requested_node_id
38
39 -If the requesting client is not in the client list:
40 -If there are no bad clients in the list and the list is full:
41 -If the id of the other client is closer (mathematically see bittorrent doc) than at least one of the clients in the list or our "friends" list:
42 -Send a ping request to the client.
43 -if not forget about the client.
44
45 -If there are bad clients and/or the list isn't full:
46 -Send a ping request to the client
47
48 When a client receives a response:
49 -Ping response
50 -If the node was previously pinged with a matching ping_id (check in the corresponding pinged list.)
51 -If the node is in the client list the matching client's timestamp is set to current time.
52 -If the node is in the "friends" list the matching client's timestamp is set to current time for every occurrence.
53 -If the node is not in the client list:
54 -If the list isn't full, add it to the list.
55 -If the list is full, the furthest away (mathematically see bittorrent doc) bad client is replaced by the new one.
56 -If the list is filled with good nodes replace the furthest client with it only if it is closer than the replaced node.
57 -for each friend in the "friends" list:
58 -If that friend's client list isn't full, add that client to it
59 -If that friend's client list contains bad clients, replace the furthest one with that client.
60 -If that friend's client list contains only good clients
61 -If the client is closer to the friend than one of the other clients, it replaces the farthest one
62 -If not, nothing happens.
63
64 -Send nodes
65 -If the ping_id matches what we sent previously (check in the corresponding pinged list.):
66 -Each node in the response is pinged.
67
68
69
70
71
72 Protocol:
73
74 Node format: [char array (node_id), length=32 bytes][ip (in network byte order), length=4 bytes][port (in network byte order), length=2 bytes][Padding , length=2 bytes]
75
76 Valid queries and Responses:
77
78 Ping(Request and response): [byte with value: 00 for request, 01 for response][random 4 byte (ping_id)][char array (client node_id), length=32 bytes]
79 ping_id = a random integer, the response must contain the exact same number as the request
80
81
82 Get nodes (Request):
83 Packet contents: [byte with value: 02][random 4 byte (ping_id)][char array (client node_id), length=32 bytes][char array: requested_node_id (node_id of which we want the ip), length=32 bytes]
84 Valid replies: a send_nodes packet
85
86 Send_nodes (response): [byte with value: 03][random 4 byte (ping_id)][char array (client node_id), length=32 bytes][Nodes in node format, length=40 * (number of nodes (maximum of 8 nodes)) bytes]
87 ex: 03[Node][Node][Node] \ No newline at end of file
diff --git a/docs/TODO.txt b/docs/TODO.txt
new file mode 100644
index 00000000..6763c8c4
--- /dev/null
+++ b/docs/TODO.txt
@@ -0,0 +1,25 @@
1Things to do now:
2
3-Network protocol for clients when they know their ips.
4
5-Start coding the gui
6
7-Get a basic im client working using the now completed DHT implementation to find the ips of your friends.
8
9-Find some good encryption libraries.
10
11-Figure out the best way to do "lossless" UDP.
12
13Things to do later:
14
15-Figure out the whole sound and video transmission.
16
17Less important.
18
19-Symmetric NATs
20 UDP hole punching on them so we need to do something else
21 (only if both the clients which try to connect to themselves are behind one)
22
23-Offline messaging protocol (text only)
24 Use your friends.(or maybe the people closest (mathematically by comparing client_id's) to you or the friend you want to send the message to).
25 The message will not be very big. Let's say we limit the maximum number of bytes for one to 1024, it means if every client stores 1024 offline messages it only takes 1 MB of ram. \ No newline at end of file
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-15 04:04:16 +0000