Decentralized StrongDC++ network
The main
goal of this network is to provide decentralized communication between StrongDC++ clients. It’s not a new protocol. The advantage is
that clients will be able to communicate (download, upload and search) with
clients who are connected to different hubs. This draft won’t describe ADC
protocol, neither process of file transfers, because it’s exactly the same as
in ADC.
The feature
will be optional. Since it can bring some privacy problems, especially in
private hubs, user will have a choice to disable it. Such client will behave as
normal client without support, it means no decentralized downloads, uploads nor
searches.
When a new
client connects to network, it has to create a node list. It’s a list of all
users connected to the network. This operation is called bootstrapping.
The only request is that user has to connect to some existing Direct Connect
hub. It’s the only situation when hub interaction is needed. The bootstrapping
client (= new connected) should indicate decentralized network support in $MyInfo (NMDC) or INF (ADC) command:
NMDC => flag 0x20
ADC => param D4<udp port>
It’s not a
goal of this draft to describe how should bootstrapping procedure be
implemented. Every client can implement it in its own way, so it should be
guaranteed that bootstrapping doesn’t require any special support from client
side. The recommended ways could be:
·
send
node list to ADC node when D4 param is detected in
INF
·
download
node list from some URL
·
send
node list to NMDC node when it has flag 0x20 in $MyInfo
and $SR command comes from this client
When
bootstrapping is done, the client doesn’t need to be connected to any hub.
The node
list is a list which contains all known clients connected to the network. It
has to content user’s CID, IP address and UDP ports for receiving decentralized
messages. The created list will be saved to disk and loaded on every startup.
Recommended format is binary form (cid1, ip1, udp1, cid2, ip2, udp2 …). When
this file doesn’t exist, bootstrapping will occur. Node list available in INF
command is attached to parameter NL in binary form.
The main
problem is that node list can contain obsolete nodes which aren’t connected to
network anymore. Due to this negative, the bootstrapping procedure will be
repeated in settable time. Users will be able to set maximum size of node list.
Also, when there are less than 100 clients in the list, bootstrapping will be
executed on connection to any Direct Connect hub. Nodes that haven’t been
online for certain time should be removed from node list.
Whole
network has no own protocol and it will use existing ADC commands. Hub-like
communication will be processed via UDP port and transfers normally via TCP
port. Passive clients will not be able to use this network, because they can’t
receive anything via these ports.
All TCP
communication can be (if client has generated certificates) encrypted using
SSLv3/TLS mechanism. UDP communication should be encrypted too, but I haven’t
found a clear solution to do it yet. DTLS provides encrypting over UDP sockets,
but it needs to create connection and do handshake for every single command.
Since
there’s no hub in the network, clients will serve as hubs alone.
When a
client joins the network (after creating node list) he will send INF command to
all nodes on its node list. Connected nodes receive this command and reply to
it with their INF. Receiving INF command means that node will be marked as
online. INF command has exactly the same format as in ADC protocol but it adds
following new parameters:
|
T4 |
16-bit
unsigned integer |
Node’s
TCP port. |
|
RE |
8-bit
unsigned integer |
Requirements
to node to send us his INF. 0 = no, 1= yes, 2 = yes with node list. |
|
NL |
Binary
string |
Node
list in binary form <CID, IP, UDP>. |
When a
client wants to leave the network, it doesn’t give a notice about it. This is
generally main problem of this network that it can contain dead nodes. When
node seems to be inactive (= no communication from it) for some time, it can be
marked as offline. There could be possibility to ping node before removing it
to ensure that it’s really offline, but it’s a business of each implementation.
When search
request is done, the SCH command shouldn’t be sent to all online nodes. The
searching node selects low number of perfect nodes and sends search request to
them along with reasonable distance. Clients receiving this request decrease
distance by one and forward it to another low number of perfect nodes. When
distance is equal to zero, the search request shouldn’t be forwarded anymore.
Each implementation has its own right to specify what “perfect node” means, but
it should be ensured that it’s not searching node. Each node should respond to
request with maximally 10 results (same limit as in ADC/NMDC). When search
request contain TTH, nodes should also provide results from partial file
sharing feature.
Every UDP
packet can be compressed using ZLIB library. Clients must support receiving
compressed and uncompressed packets; therefore a single mark will be added at
the beginning of every compressed packet to differentiate it. When byte 0xc1 is
detected as the first byte in packet, it must be decompressed before
processing.