DFAV

Ideas for ADC may be presented here for others to review and point out flaws or further improve the idea.
Forum rules
If you have an account on the wiki, remember to update the ADC Proposals page for new ideas.

http://dcbase.org/wiki/ADC_Proposals_list
Post Reply
en_dator
Member
Posts: 72
Joined: 01 Apr 2008, 19:24

DFAV

Post by en_dator » 23 Nov 2008, 11:58

Seeing as hublists are a big issue for many users (the aim of people is to find hubs and the public hubs what users to find them) I feel that a method to let users themselves create a hub database sounds like a really good idea.

The difficult part with creating a distributed version of a hublist is that it must involve both clients and hub softwares to really provide a useful feature. (The hub needs to set whether its public or private, client users should not be allowed to set this).

In the proposal it says "The idea behind this extension is to generate a public hublist from the users favorite hublist", frankly this will not work as there is too much information missing, but more importantly it will never create a large enough hublist to be of any use. It is much better to implement a separate feature that stores information about the hubs and sends/receives that information using already existing techniques.

Instead I have another idea how to implement a distributed hub database: it is more complex and will require more work for developers I think, but on the other hand it will give more to the users (which I believe is the important part here).

The idea behind this extension is that each client keeps a database of hubs with information that can be shared with other users on request.

GFA / RFA

Contexts: F, T, C, U

After a succesful login the client send GFA to the hub, to ask the hub for its information. The hub answers with a RFA containing
PUBLIC (1/0), NI, HH, DE, UC, SS, MS, ML, XU, MC. (using same definitions and format as for the PING extension, no need to invent another wheel).
If public flag is set to 0 (private) it must not share that information to other clients (and need not store it ).

The information is stored locally in a binary crc checked file to avoid tampering between sessions.

Toghether with the information from the hub is also stored the last succesful login time, status (on/offline). User count and share may be updated by the client itself if it differs from what the hub sent, other information should not be changed.
If any of the hub settings are changed that are included in the list it must send a RFA to all users in the hub that supports DFAV.

A client can send GFA to another client, as single statement or toghether with a filter (variable string to match variable string to match ...)
The second client responds with a binary transfer of a bzip compressed xml file in the ordinary hublist format (remember the wheel guys).
A suggestion would be to use the already existing method of filelist transfer (i.e. use filelist transfer slots/minislots).

If any of the received hubs have Public flag set to 0 (i.e. is private) it must remove that hub from the database.

Only hubs which sends a public flag set to 1 should be shared to others, this way we make sure only hubs that really are public are spread.
The client stores the received hub information in the same binary file as the hubs that itself has collected information about and can then share them all to the next user that asks for them (this is how the list becomes large and useful).

Now there are some obvious disadvantages to this method, so lets go trough them all;

old hubs
Yes this is very likely, so some kind of function to remove old hubs could probably be useful, or maybe the client should only keep/share hubs that has a connection date newer than XX days??

duplicate hubs
Yes this will also happen, the client need to be able to parse the incomming hub information to avoid duplicate entries (same hub description on different ports for example).

fake hubs
This is a tricky one.

increased bw usage by large bz2 hubdata
Restrict the filesize to a maximum of some resonable number (2mb?, 1000 hubs = 70kb so a few mb should be more than enough), maybe only send xxxx number of the newest hubs is an even better option?

With this method the already existing gui for public hublists can still be used in the clients (and users wont have to deal with a new one, also a good point).
What we loose with this method is two pieces of information from the hublists, reliability and rating, and also we loose the advertising possibility (a new hub have nowhere to add it self to let people know it is there), the only way a new hub will be found is by word of mouth. This is a disadvantage that I do not have a solution for yet.

what do you guys think?

/1dat

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

Re: DFAV

Post by Pietry » 23 Nov 2008, 19:43

First of all, you have good ideas and criticism is always welcome :P
About the sharing of hubs, the user should be able to check if the hub is distributable or not ( eg. in his favorites list just check the hub if he wants to share it or not , default: share ).
Also, about new hubs, one opening a new hub just has to add it to his favorites and then login to a lot of big hubs and use DFAV. This way, all the users in the hubs he joins will eventually get the hub address from him via the DFAV mechanism.
Getting new hubs from the users should be on demand or at client's discretion ? eg. should the user click a button similar to : search for new hubs or should the client auto add them to favorites list ? I have the following suggestion : add a new default hublist named local.xml , when the user opens up public hubs with this hublist, just call a GFA around all connected clients and create a new favorites list from which the user can choose to connect and/or add to it's own favorites list .
Just someone

en_dator
Member
Posts: 72
Joined: 01 Apr 2008, 19:24

Re: DFAV

Post by en_dator » 24 Nov 2008, 18:21

Pietry wrote:First of all, you have good ideas and criticism is always welcome :P
Thanks (it will not be the last one, I'm sure)
Pietry wrote:About the sharing of hubs, the user should be able to check if the hub is distributable or not ( eg. in his favorites list just check the hub if he wants to share it or not , default: share ).
I agree that the user should be able to decide which of the hubs he has in his favs he should share, I do however not agree that the default should be to share (think for example what will happen when a user which is in some private hubs starts to use a client with this function implemented, he will instantly begin to share those adresses around, that will definitely ban any new client from that cathegory of hubs) (and yes I know he should fix that before connecting - but we all know that most people don't).

One of the reasons I proposed that the hub itself should set if it is public or not(shareaable or not) is because I see that as one way to get a new client to be more tolerated in places where new clients are often seen as threats. And getting people to actually upgrade their clients is one of the goals.
Pietry wrote:Also, about new hubs, one opening a new hub just has to add it to his favorites and then login to a lot of big hubs and use DFAV. This way, all the users in the hubs he joins will eventually get the hub address from him via the DFAV mechanism.
:D of course. How stupid of me to not see that.

Post Reply