Decentralized StrongDC++ network Draft

[Toast]

Author: BigMuscle

1 Introduction

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.

2 Connecting a new client

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.

3 Node list

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.

4 Communication

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.

4.1 Joining the network

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>.


4.2 Leaving the network

When a client wants to leave the network, it must send QUI command to all online nodes. Such client will be marked as offline.

4.3 Searching

When search request is done, the SCH command will be sent to all online nodes. These nodes should respond 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.

4.4 Private messaging
5 Extensions
5.1 ZLIB compression

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.

[3dfx]

interesting,gonna test it

[Toast]

hasn't been released yet this is just a draft not implemented

[Big Muscle]

The first implementation has already been commited to StrongDC++ SVN

[Toast]

Wonder if RSX++ and ApexDC++ and AirDC++ are aslo gonna implement this feature

[adrian_007]

of course... at least rsx++ inherit it, anyway.

[3dfx]

of course... at least rsx++ inherit it, anyway.

thats great to know

[Toast]

Well it doesnt have too one could take out the code if its an unwanted feature

[Big Muscle]

If you have any proposal about this feature, please write it here... I also think that downloading from decentralized network should be allowed only when user share some amount of data.