Decentralized StrongDC++ Network

Discussion and questions about clients
Locked
Toast

Decentralized StrongDC++ Network

Post by Toast » 21 Jul 2008, 10:46

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.

rhys_rhaven
Newbie
Posts: 9
Joined: 08 Oct 2008, 16:07

Re: Decentralized StrongDC++ Network

Post by rhys_rhaven » 09 Oct 2008, 02:01

Question: Isn't that against the goal of ADC? Direct Connect is centralized. Its supposed to be. Its really the only one of its kind for easy file sharing across large bandwidth, big server networks, were decentralization's benefits (availability due to no single node being mission critical) are completely outweighed by the increased bandwidth and reduced efficiency of searching.

I thought decentralization sacrifices too much, and ADC is the alternative. The only other method of course is bittorrent.

Pietry
Senior Member
Posts: 328
Joined: 04 Dec 2007, 07:25
Location: Bucharest
Contact:

Re: Decentralized StrongDC++ Network

Post by Pietry » 09 Oct 2008, 07:35

ADC of course is centralized. So this is how ADC works. But nobody stops having a decentralized version. This could result into more flexible network possibilities.
Just someone

Big Muscle
Junior Member
Posts: 39
Joined: 01 Jul 2008, 19:27

Re: Decentralized StrongDC++ Network

Post by Big Muscle » 25 Jun 2009, 11:15

The decentralized network has been completely redesigned. It's testing version is available in StrongDC++ SVN respository and protocol specification is in StrongDC++ forum. Compiled debug version will be soon.

Pietry
Senior Member
Posts: 328
Joined: 04 Dec 2007, 07:25
Location: Bucharest
Contact:

Re: Decentralized StrongDC++ Network

Post by Pietry » 25 Jun 2009, 17:12

Nice to hear it. Perhaps we will have the chance to test it somehow :)
Just someone

Big Muscle
Junior Member
Posts: 39
Joined: 01 Jul 2008, 19:27

Re: Decentralized StrongDC++ Network

Post by Big Muscle » 26 Jun 2009, 12:12

I will publish it during the weekend, just need to tweak some stuff. Currently there are about 10 users active in this network :)

Toast

Re: Decentralized StrongDC++ Network

Post by Toast » 26 Jun 2009, 23:10

Nice gonna update the wiki when the spec is done :)

darkKlor
Senior Member
Posts: 100
Joined: 30 Dec 2008, 14:59

Re: Decentralized StrongDC++ Network

Post by darkKlor » 30 Jun 2009, 14:40

Uh just curious, why allow the feature for NMDC? Surely we should be trying to migrate away from it...
Creating ADC-only features promotes this, despite there being no technical issue why it can't also be an NMDC feature.

Big Muscle
Junior Member
Posts: 39
Joined: 01 Jul 2008, 19:27

Re: Decentralized StrongDC++ Network

Post by Big Muscle » 03 Jul 2009, 11:24

The specification in this forum is old. Current implementation is ADC only.

First testing version is available for download: http://strongdc.sourceforge.net

Locked