Decentralizing the centralized network

The centralized nature of DC is quite apparent. A client connects to a hub, which in turn is used as the central point for all communication, except the raw file transfers. Also, clients connect to hub lists that are also, essentially, a central point for all communication. (Well, one only access the site and download a file.)

What can we do, then?

A solution for this problem would be to have multiple hubs acting as one entity. Something similar to IRC, that is. There are already ways to do this, have a look at Hublink for NMDC and the “IHUB” initiative started by qhub.

We need to consider what the clients are capable of. During file transfer information exchange, one party is considered as “hub” and the other as “client”. This mean that there’s an abstract thought of thinking of clients as hubs. So, if clients may act as a hub, in some sort of limited sense, how can the clients act (more) as a hub?

The most obvious instance for me is “private messages”. That is, a PM in NMDC and ADC (BASE, at least) is routed through the hub. This even mean that the hub can manipulate the message (or simply avoid sending it). There is a solution to this though, and that would be to connect to the other party (as one would do when trying to download a file) and avoid having the messages being routed through the hub. (This can easily be achieved through ADC.)

Further, in ADC, one might send a private message to an entire group. We can use this to our advantage yet again by having a member of the group acting as the “hub”, so all messages are routed through that client. (Yes, I’m aware that there might be a problem if everyone is in passive mode…)

In a secure environment, perhaps even allowing certain clients act as a hub; that is, something similar as “hub link”, but for certain trusted clients only. (QuickDC apparantly is able to switch between being a real hub and true client.)

An important instance, which possibly have gotten the most attention the past year or so, is the hub list situation. Take down the address of a hub list, and you cause havoc.

DC++ formed a solution for this by caching the hub lists it has been able to download. This mean that we only “need” to access a list once, to have a semi-useful list. But how can we take it further? A solution that has been discussed is to use a service similar to Coral, where the actual file would be cached on the net.

Another solution would be to use invent a new command (a new INF-parameter in ADC would suffice, I think), where we’d say “Hey. This hub list address doesn’t work anymore. People, send me a new one!” (Eg, “NH” where the address would be considered as “this hub list doesn’t work”.) The clients could even send a hub list (or using some other command) when connecting to the hub, meaning “I got this or these list(s)”. The hub would then respond with “Oh, I got these ones”, where the addresses would be all of the hub lists the hub has gathered from the clients.

Another possiblity would be for clients and hubs to agree on another extension, where one requests the actual hub list file and the other party sends the file. Of course, a hub list that is only in circulation and never re-downloaded will be outdated in a while. So, we obviously need to download the hub list for ourselves, at intervals. However, this interval can, with mentioned techniques, be much greater than the situation we have now.

Are there other ways you can think of where we can decentralize DC?

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”

5 Responses to Decentralizing the centralized network

  1. djoffset says:

    Just to clarify: “QuickDC apparantly is able to switch between being a real hub and true client.”

    It would be more accurate to say, that QuickDC is inherently multi protocol,
    it acts as a ADC client, ADC hub, NMDC client, HTTP server at the same time.

    I have some suggestions for decentralizing DC, but more on that another day :-)

  2. djoffset says:

    It might be a good idea to look at how Gnutella has solved the hublist issues using the “gwebcache”.

  3. mpioner says:

    maybe DHT?
    Centralizing -> Decentralizing
    BitTorrent -> DHT!
    eMule -> Kademlia!
    DC++ ->supports this?

  4. Todd Pederzani says:

    djoffset, should it then talk about how the gwebcache became depreciated because of abuse and not enough new gwebcaches being run? The current way of bootstrapping in Gnuella, last I knew, was UHC, the UDP Host Cache.

  5. djoffset says:

    Todd, hm, I haven’t been paying much attention to gnutella lately, but definitively! :-)

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: