StarMirror/toxcore
1
0
Fork 0
mirror of https://github.com/irungentoo/toxcore.git synced 2024-03-22 13:30:51 +08:00
Code Issues Projects Releases Wiki Activity

Fixed one possible bug in the DHT and added a basic TODO list.

Browse Source 
Fixed a possible segfault which could have been cause by handling an
empty packet.
This commit is contained in:
irungentoo 2013-06-25 17:16:45 -04:00
parent adc9c64fe6
commit 1837745d96
4 changed files with 121 additions and 87 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

92
README.md
View File

@ -11,7 +11,7 @@ Proposal of a free as in freedom skype replacement:
-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)
-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.)
-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?))
-Use something torrent DHT style so that peers can find the ip of the other peers when they have their id.
@ -32,6 +32,10 @@ Proposal of a free as in freedom skype replacement:
5.Reliable sending of data larger than the maximum packet size.
...
-------TODO-------:
See: docs/TODO.txt
-------Important-stuff--:
Use the same UDP socket for everything
@ -39,90 +43,6 @@ Proposal of a free as in freedom skype replacement:
-------Details---------:
DHT protocol:
Follows pretty much the principle of the torrent DHT: http://www.bittorrent.org/beps/bep_0005.html (READ IT)
see: docs/DHT.txt
But:
Vastly simplified packet format.
Boostrapping:
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.)
Basics (All the numbers here are just guesses and are probably not optimal values):
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.
"friends" list: A list containing the node_ids of all our "friends" or clients we want to connect to.
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"
Two pinged lists:
-One for storing a list of ips along with their ping_ids and a timestamp for the ping requests
-One for storing a list of ips along with their ping_ids and a timestamp for the get nodes requests
Entries in the pinged lists expire after 5 seconds.
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.
Entries in client list and "friends" list expire after 300 seconds without ping response.
Each client stores a maximum of 32 entries in its client list.
Each client in the client list and "friends" list is pinged every 60 seconds.
Each client in the client list and "friends" list has a timestamp which denote the last time it was successfully pinged.
If the corresponding clients timestamp is more than 130 seconds old it is considered bad.
Send a get nodes request every 20 seconds to a random good node for each "friend" in our "friends" list.
Send a get nodes request every 20 seconds to a random good node in the client list.
When a client receives any request from another:
-Respond to the request
-Ping request is replied to with with a ping response containing the same ping_id
-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
-If the requesting client is not in the client list:
-If there are no bad clients in the list and the list is full:
-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:
-Send a ping request to the client.
-if not forget about the client.
-If there are bad clients and/or the list isn't full:
-Send a ping request to the client
When a client receives a response:
-Ping response
-If the node was previously pinged with a matching ping_id (check in the corresponding pinged list.)
-If the node is in the client list the matching client's timestamp is set to current time.
-If the node is in the "friends" list the matching client's timestamp is set to current time for every occurrence.
-If the node is not in the client list:
-If the list isn't full, add it to the list.
-If the list is full, the furthest away (mathematically see bittorrent doc) bad client is replaced by the new one.
-If the list is filled with good nodes replace the furthest client with it only if it is closer than the replaced node.
-for each friend in the "friends" list:
-If that friend's client list isn't full, add that client to it
-If that friend's client list contains bad clients, replace the furthest one with that client.
-If that friend's client list contains only good clients
-If the client is closer to the friend than one of the other clients, it replaces the farthest one
-If not, nothing happens.
-Send nodes
-If the ping_id matches what we sent previously (check in the corresponding pinged list.):
-Each node in the response is pinged.
Protocol:
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]
Valid queries and Responses:
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]
ping_id = a random integer, the response must contain the exact same number as the request
Get nodes (Request):
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]
Valid replies: a send_nodes packet
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]
ex: 03[Node][Node][Node]

4
core/DHT.c
View File

@ -15,14 +15,16 @@ int sendpacket(IP_Port ip_port, char * data, uint32_t length)
//Function to recieve data, ip and port of sender is put into ip_port
//the packet data into data
//the packet length into length.
//dump all empty packets.
int recievepacket(IP_Port * ip_port, char * data, uint32_t * length)
{
ADDR addr;
uint32_t addrlen = sizeof(addr);
(*(int *)length) = recvfrom(sock, data, MAX_UDP_PACKET_SIZE, 0, (struct sockaddr *)&addr, &addrlen);
if(*(int *)length == -1)
if(*(int *)length <= 0)
{
//nothing recieved
//or empty packet
return -1;
}
ip_port->ip = addr.ip;

87
docs/DHT.txt Normal file
View File

@ -0,0 +1,87 @@
DHT protocol:
Follows pretty much the principle of the torrent DHT: http://www.bittorrent.org/beps/bep_0005.html (READ IT)
But:
Vastly simplified packet format.
Boostrapping:
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.)
Basics (All the numbers here are just guesses and are probably not optimal values):
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.
"friends" list: A list containing the node_ids of all our "friends" or clients we want to connect to.
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"
Two pinged lists:
-One for storing a list of ips along with their ping_ids and a timestamp for the ping requests
-One for storing a list of ips along with their ping_ids and a timestamp for the get nodes requests
Entries in the pinged lists expire after 5 seconds.
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.
Entries in client list and "friends" list expire after 300 seconds without ping response.
Each client stores a maximum of 32 entries in its client list.
Each client in the client list and "friends" list is pinged every 60 seconds.
Each client in the client list and "friends" list has a timestamp which denote the last time it was successfully pinged.
If the corresponding clients timestamp is more than 130 seconds old it is considered bad.
Send a get nodes request every 20 seconds to a random good node for each "friend" in our "friends" list.
Send a get nodes request every 20 seconds to a random good node in the client list.
When a client receives any request from another:
-Respond to the request
-Ping request is replied to with with a ping response containing the same ping_id
-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
-If the requesting client is not in the client list:
-If there are no bad clients in the list and the list is full:
-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:
-Send a ping request to the client.
-if not forget about the client.
-If there are bad clients and/or the list isn't full:
-Send a ping request to the client
When a client receives a response:
-Ping response
-If the node was previously pinged with a matching ping_id (check in the corresponding pinged list.)
-If the node is in the client list the matching client's timestamp is set to current time.
-If the node is in the "friends" list the matching client's timestamp is set to current time for every occurrence.
-If the node is not in the client list:
-If the list isn't full, add it to the list.
-If the list is full, the furthest away (mathematically see bittorrent doc) bad client is replaced by the new one.
-If the list is filled with good nodes replace the furthest client with it only if it is closer than the replaced node.
-for each friend in the "friends" list:
-If that friend's client list isn't full, add that client to it
-If that friend's client list contains bad clients, replace the furthest one with that client.
-If that friend's client list contains only good clients
-If the client is closer to the friend than one of the other clients, it replaces the farthest one
-If not, nothing happens.
-Send nodes
-If the ping_id matches what we sent previously (check in the corresponding pinged list.):
-Each node in the response is pinged.
Protocol:
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]
Valid queries and Responses:
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]
ping_id = a random integer, the response must contain the exact same number as the request
Get nodes (Request):
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]
Valid replies: a send_nodes packet
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]
ex: 03[Node][Node][Node]

25
docs/TODO.txt Normal file
View File

@ -0,0 +1,25 @@
Things to do now:
-Network protocol for clients when they know their ips.
-Start coding the gui
-Get a basic im client working using the now completed DHT implementation to find the ips of your friends.
-Find some good encryption libraries.
-Figure out the best way to do "lossless" UDP.
Things to do later:
-Figure out the whole sound and video transmission.
Less important.
-Symmetric NATs
UDP hole punching on them so we need to do something else
(only if both the clients which try to connect to themselves are behind one)
-Offline messaging protocol (text only)
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).
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.