Client: Add support for all entries in a Round Robin set as broker candidates

wlanslovenija / tunneldigger

L2TPv3 VPN tunneling solution

http://tunneldigger.readthedocs.org/

Other

72 stars 52 forks source link

Client: Add support for all entries in a Round Robin set as broker candidates #81

Open pmelange opened 6 years ago

pmelange commented 6 years ago

It would be really useful to have all available endpoints with a single given Round Robin DNS entry as possible broker candidates. This simplifies a lot on the client side while allowing the broker side to add additional servers.

kaechele commented 5 years ago

What you're suggesting is to read all entries in a RRset and then add every one of the items to the list of broker candidates, right? Because that would be something different than Round Robin DNS, which the tunneldigger client already does.

pmelange commented 5 years ago

Yes, exactly.

kaechele commented 5 years ago

Okay, looking at it, I think it can be done.

I found a corner case that would need to be checked: Currently, there is a defined maximum of 10 brokers that the client will handle. Given a situation in which a round-robin DNS query yields more than 10 brokers. What should the defined behaviour be? Also we'd need to think about the case where more than one DNS name was given as a parameter and the collective number of responses is > 10. Do we just choose the first 10 or do we balance between the given DNS responses?

pmelange commented 5 years ago

It also depends on what type of broker selection is being used. I use 'usage' based.

With 'usage' and 'random' , I think it would make more sense to balance between the given dns entries.

But if the 'first' broker selection is used, then definitely go through all the dns entries of the first hostname before the others.

The limit of 10 brokers is a separate issue. In my personal situation it does not have an impact. But maybe it would be nice to allow setting MAX_BROKERS at compile time.

SvenRoederer commented 5 years ago

I had a look into the code as I was interested in checking for support of the SRV-RR. SRV-RRs might give some advantages:

you can define priorities --> e.g. 10 hosts with equal prio to shuffle around
you can define weighting inside a priority --> not sure if this can be useful
each referenced host can define it's own port --> flexible configuration than having to use the same port on all brokers in the RoundRobin-list

I think the SRV-RR lookup should be supplied with a separate parameter which can not be combined with "-b".

pmelange commented 5 years ago

The wikipedia link for "SRV record" is https://en.wikipedia.org/wiki/SRV_record

pmelange commented 3 years ago

I have recently modified the Freifunk tunneldigger init and hotplug scripts to be able to use SRV records. The changes can be seen here https://github.com/Freifunk-Spalter/packages/commit/29943b0d10ac3e04322dbe222e0c6453a37b49e3

Instead of having tunneldigger itself get an SRV record, the init and horplug scripts get the SRV record and add them each as single "-b" options.