Hubs Network

[verni0]

Hi,

I am wondering, have you thought about building a Hubs Network. This will be somehow like a Super-DC++ network where only hubs are allowed.
This way you will have a global P2P network with two types of peer: "normal" Peers - users and Super-Peers - hubs.

Having this global DC++ network, a user can submit a search on the hub he is connected and get results from all the hubs in the Super-DC++ network. So, a user needs to/can connect at only one hub of the Super-DC++ network.

Here, there are details that need discussions and analysis, and if you did not talk about this already, I think it will be an interesting point for feature work.

Best regards,
verni

[PseudonympH]

Hub networks already exist, although they aren't usually interconnected except for chat sometimes. There is a whole set of commands for multihub stuff, but I think it would be much easier to make it transparent to the user like it is with HTTP server farms. Simply adding a prefix for which hub the user is actually connected to would work well, I think. Keep in mind that some people have shares so large that receiving so many searches would result in them having 100% CPU usage: just ask fusbar.

[cologic]

This has been extensively discussed.

[PseudonympH]

From reading a good amount of that, it's nice to see that you and I think alike.

[verni0]

Hub networks already exist, although they aren't usually interconnected except for chat sometimes. There is a whole set of commands for multi hub stuff...

This has been extensively discussed.

I see what you mean by multi-hub but my idea is a bit simpler.

I think the main use of DC++ is for downloading. If I know the user that has the file I need I can get it without using any hub (generally speaking, because I connect directly to him).
Until here everything is fine.
But if I do not know the user that has my file I have to connect to a hub and search there and if I do not find the file I’m looking for I have to disconnect and connect to another hub, until I find it. So, one problem here is to which hub I should connect in order to find my file fast.

So my idea was a user connects to a single hub, does not matter witch (normally would by a hub close to him). This hub is part of a hub network (Super-DC++ network) and there each search query is submitted to all the hubs and a user gets results from all the hubs.
Of course, that the user gets all those results thou the hub he is connected. So for each user’s search, the hub to which this user is connected sends a search query thought the hubs network, collects the results and then sends all the results back to the user.

Only search uses this hubs network, the rest, chat, user list and so on is local to the hub.
In order to make things work faster the hubs may have some routing indices maintained among them (routing indices based on user’s shares) so the query goes to only the hubs that may answer it.

This idea is only theoretically, it needs some research and analysis, but I think you should give it a chance.

Best regards,
verni

[cologic]

But if I do not know the user that has my file I have to connect to a hub and search there and if I do not find the file I?m looking for I have to disconnect and connect to another hub, until I find it. So, one problem here is to which hub I should connect in order to find my file fast.

MoGLO automates this.

So my idea was a user connects to a single hub, does not matter witch (normally would by a hub close to him). This hub is part of a hub network (Super-DC++ network) and there each search query is submitted to all the hubs and a user gets results from all the hubs.

You're describing $MultiSearch. NMDC 1.x implements it. I know nothing of NMDC 2.x. DC++ hasn't, but some mods have (oDC used to, perhaps?). Further, many new hubs do not support it. DC used to support your suggested usage, yet it's not currently favored.

Of course, that the user gets all those results thou the hub he is connected. So for each user?s search, the hub to which this user is connected sends a search query thought the hubs network, collects the results and then sends all the results back to the user.

This is a passive mode search. $MultiSearch intentionally worked only for active mode searches which don't rely on hubs' relaying search responses, presumably due to bandwidth concerns (maybe those more directly involved can elaborate or refute this).

Only search uses this hubs network, the rest, chat, user list and so on is local to the hub.

This approach provides no effective way for DC++ to verify that a client connecting to it exists: $MultiSearch support without userlist sharing means that it has to simply accept that

Code: Select all

$MyNick I_could_be_on_another_hub_in_the_network_in_question|

in a client-client connection wolud have to be trusted, rather than checking on hubs the client's currently connected to, ensuring an extant user.

In order to make things work faster the hubs may have some routing indices maintained among them (routing indices based on user?s shares) so the query goes to only the hubs that may answer it.

Something like this?

[Todi]

Hub-Link

[HaArD]

I am assuming off the shelf DC++ clients, if you customized the client, or used something else (DC:Pro, NMDC, DCGUI) then some of these statements might not be true....

Sharing search results without sharing the Userlist is pointless. DC++ and deriviatives will not try to download from a User which is not Online. Online means the UserName shows in the Userlist of one or more hubs that you are connected to.

Furthermore, unless the hub can identify that the connection request you have sent, is for a user on another hub, and relay that information to that other hub, you still cannot initiate the connection to that user.

Within the confines of the current DC protocol Hub-Link provides the ability to link multiple hubs together into a seamless Hub Network where users can interact with each other as if they were on the same hub.

The Enable Flag in the Hub-Link App. allows for various degrees of linkage.

The current release includes support for NMDC v1 and SDCH. An LUA script for PtokaX hubs is in final testing. Documentation of all Hub-Link commands and how DC Protocol commands are handled is available to anyone who wants to develop support for any other Hubsoft. Any hubsoft which allows for scripting or plug-ins could theoretically support a Hub-Link connection.

cologic,

You are absolutely right about $MultiSearch.
oDC is the only client that ever supported it as far as I know and Opera eventually removed that support as the implementation was so hopelessly flawed it could never work as intended.

[junkie86]

I wanted to search all the existing hubs all at the same time so I went to the forum to see if other people thought the same like me. And I found this topic. I saw the idea of Verni and that idea is similar to mine.(I don't know how DC++ works)

It will be a very good option if you van search all the hubs at the same time, the network will be a lot bigger. And you won't have any problems downloading files that are scarce at this moment.(in the hubs you are connected with)

And beginning users have no clue which hub they will connect to. So if you explain that they can search all the hubs, the use of DC++ will be easier and DC++ will be a better program.

[cologic]

I wanted to search all the existing hubs all at the same time so I went to the forum to see if other people thought the same like me. And I found this topic. I saw the idea of Verni and that idea is similar to mine.

You should have then read my response to the idea of Verni:

But if I do not know the user that has my file I have to connect to a hub and search there and if I do not find the file I?m looking for I have to disconnect and connect to another hub, until I find it. So, one problem here is to which hub I should connect in order to find my file fast.

MoGLO automates this.

It will be a very good option if you van search all the hubs at the same time, the network will be a lot bigger. And you won't have any problems downloading files that are scarce at this moment.(in the hubs you are connected with)

How will the network be bigger?

[verni0]

But if I do not know the user that has my file I have to connect to a hub and search there and if I do not find the file I am looking for I have to disconnect and connect to another hub, until I find it. So, one problem here is to which hub I should connect in order to find my file fast.

MoGLO automates this.

Well... MoGLO....

It connects to all the hubs (one at a time) and does my search...

It is a good solution for my problem, but if this problem is to be the system's problem (DC++ system as a whole) then this is a bad solution.

Remember about the HTTP protocol... they made this protocol stateless and then they wanted it to have states within it so they invented new technologies to overcome the stateless (ActiveX, Java Applets, JavaScript and cookies).

So, MoGLO over DC++ is analogous to the "new technologies" over HTTP.

But, what happened if they had changed the HTTP protocol, so to be stateful...

Kind regards,
verni

[GargoyleMT]

It is a good solution for my problem, but if this problem is to be the system's problem (DC++ system as a whole) then this is a bad solution.

That's the crux of the it, no? Everyone does not agree that lack of global search is a problem.