idk/muwire
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update for use with signed datagrams and Destination multiplexing

Browse Source
This commit is contained in:
Zlatin Balevsky
2018-07-06 05:00:13 +01:00
parent 30ba494ac0
commit c150e22651
2 changed files with 7 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
doc/design.md
View File

@@ -2,13 +2,13 @@
### Initial Bootstrap
Initial bootstrap into the MuWire network is done in a similar fashion to Gnutella. Dedicated bootstrap servers ("HostCaches") listen for incoming I2P Datagrams which contain requests for addresses of ultrapeers. The incoming datagram has a flag whether the requesting node is an ultrapeer or a leaf; if the node claims to be an ultrapeer it may be added to the list of known ultrapeers by the HostCache. Implementors of HostCaches are free to choose other discovery strategies such as crawling, active polling and so on.
Initial bootstrap into the MuWire network is done in a similar fashion to Gnutella. Dedicated bootstrap servers ("HostCaches") listen for incoming I2P Datagrams which contain requests for addresses of ultrapeers. The incoming signed datagram has a flag whether the requesting node is an ultrapeer or a leaf; if the node claims to be an ultrapeer it may be added to the list of known ultrapeers by the HostCache. Implementors of HostCaches are free to choose other discovery strategies such as crawling, active polling and so on.
In response to the request, the HostCache sends back an I2P datagram containing b64 destinations of selected ultrapeers. The requesting client can then choose to close the I2P tunnel that it used to send the request because it will now know about ultrapeers to connect to.
In response to the request, the HostCache sends back an I2P datagram containing b64 destinations of selected ultrapeers.
### Connectivity to peers
Each node, be it leaf or ultrapeer will open two I2P tunnels - one for incoming I2P datagrams containing search results and incoming streaming connections for HTTP file transfer requests. In addition to this, ultrapeers will open an additional tunnel for incoming MuWire protocol connections. This simplifies implementation because the different pseudo-sockets can have dedicated logic to handle traffic, i.e. there is no need to multiplex between MuWire protocol connections and incoming HTTP requests.
Each node will register a single I2P Destination and then multiplex between I2P streaming and signed datagram protocols. The streaming pseudo-socket will further multiplex between MuWire protocol connections and HTTP1.1 requests.
### Search request propagation

10
doc/wire-protocol.md
View File

@@ -1,6 +1,6 @@
# MuWire network protocol
The MuWire protocol operates over a TCP-like streaming layer offered by the I2P streaming library, except for "Result" type messages which are delivered of I2P datagrams.
The MuWire protocol operates over a TCP-like streaming layer offered by the I2P streaming library, except for "Result" type messages which are delivered in signed I2P datagrams.
## Handshake
@@ -65,7 +65,7 @@ Sent when the leaf wants to find the addresses of more ultrapeers to connect to.
#### "Search"
Sent by a leaf when performing a search. Contains the reply-to b64 destination for I2P datagrams.
Sent by a leaf when performing a search. Contains the reply-to b64 destination for signed I2P datagrams.
```
{
@@ -74,7 +74,7 @@ Sent by a leaf when performing a search. Contains the reply-to b64 destination
uuid: "asdf-1234..."
firstHop: false,
keywords : "great speeches"
replyTo : "asdfasf..."
replyTo : "asdfasf...b64"
}
```
@@ -107,7 +107,7 @@ This message starts with a single byte which indicates the size of the bloom fil
This message starts with two unsigned bytes indicating the number of patches included in the message. Each patch consists of 3 bytes, where the most significant bit indicates whether the corresponding bit should be set or cleared and the remaining 23 contain the position within the Bloom filter that is to be patched.
### Any node to any node over datagrams
### Any node to any node over signed datagrams
Search results are sent in "Result" type message over an I2P datagram, uncompressed. The format of this message is the following:
@@ -116,7 +116,6 @@ Search results are sent in "Result" type message over an I2P datagram, uncompres
type: "Result",
version: 1,
uuid: "asdf-1234-...",
address : "asdfqwer...b64"
results : [
{
name: "File name 1",
@@ -138,6 +137,5 @@ Search results are sent in "Result" type message over an I2P datagram, uncompres
```
* The "uuid" field must match the uuid of the "Search" message which triggered this search result.
* The "address" field is the I2P Destination listening to incoming HTTP requests that can serve the file
* The "altlocs" list contains list of alternate locations in b64 format that may also have the file.
* The "pieceSize" field is the size of the each individual file piece (except possibly the last) in powers of 2