DNS SRV support to enable automagic failover

[ScratchMonkey]

This sounds complicated, but it's actually pretty easy. The idea is that, when a server name is supplied, you don't immediately resolve it directly to an IP. Instead, you look up any "SRV" DNS records for that name. These will have a priority, weight, and server name as the value part. You use the priority to pick one of several servers (this gives you failover), and then use the weight to pick among servers of the same priority (this gives you load balancing, but not really useful for this case).

Once you've picked a server, you then look up its IP in the usual way.

If you don't find a SRV record for a name, you just look it up like a traditional server name.

I'm guessing you're using INDY classes for TCP/IP, so you can use the DNSResolver class to do the SRV lookup.

Now a clan can operate multiple TS servers, at different locations, with different SRV priority values. If the primary server goes down, The TS client can automatically pick the next-best one in the list.

[R. Ludwig]

hmm..

i thoughts this tool is for gaming and no real war army support ?

it cant be that hard to make 2-3 bookmarks ? instead of the task u explained...

[N. Werensteijn]

Automatic fail over would mean that there is some sync. system that synchronizes the 2 teamspeak servers.
Example.. Primary server goes down. Then the backup server needs to start/ take over (maybe even with same channels etc)

Then suddently primary server comes back. But there are a lot of people on the backup server now. What server should new people go to. All this needs to programmed in the ts servers.

And like ralf said. This is not realy an issue for this kind of application. Its not like this is the database of amazone.com :)

So:
1: This is NOT easy to implement. The idea is simple enough. But the details are a nightmare.
2: How many users (server hosters) will have the ability for this kind of dns support and have backup ts servers standing by.

Agreed, its a cool thing to do. But not realy worth the effort for this program

[ScratchMonkey]

As you say, bookmarks would do the same. I wasn't thinking of the servers being aware of this. This would primarily be for servers going down for extended periods (say a day or two) and people coming on and not knowing about the backup server being available. In my case, my clan has a primary server and a couple of backups run by DNS-savvy admins.

Most people who have a domain can request the SRV records be installed by their hosting service. DNS people are getting more familiar with SRV ever since Microsoft started using them for much of Win2k's infrastructure.

But yeah, I don't want you to be distracted into implementing this when you could be working on core functionality. This is one of those cases where it's frustrating that this isn't open source, as I could implement this myself and then submit the patches back to you.

[ScratchMonkey]

Another case where this would be useful: A vendor who supplies multiple TS servers from a single physical server, and his customers want to use DNS names of their own to name their server.

To facilitate this, how about adding an SDK hook in the client at the server name parsing step? If the hook is present, the plugin takes the text contents of the edit field and does all the DNS magic, returning an IP and port number to use. If not, you do your traditional parsing.

I don't know how your SDK will work, or whether you've given thought to plugins, but one way to hook this would be to add an INI parameter for ServerNameParser that takes a DLL (or SO) name and entrypoint as a parameter. The API would take two arguments, a C null-terminated string (input) and a pointer to a standard sockaddr structure to return the IP and port number in. Or two pointers to get the IP and port separately as 32 bit integers. I think Windows API's return a boolean indicating success.

I could then add code to do the SRV stuff and you could add that at your leisure to your main code base.

In practice, the TSS vendor creates a DNS record for each server that looks like this:

_teamspeak._udp.customer.vendor.com SRV 0 0 1234 ts4.vendor.com

The customer then puts a CNAME in his own DNS that looks like this:

_teamspeak._udp.ts.customer.com CNAME _teamspeak._udp.customer.vendor.com

The end user (who knows nothing of SRV records or DNS) puts "ts.customer.com" in his TS client. The client looks up a SRV record for _teamspeak._udp.ts.customer.com, follows the alias to _teamspeak._udp.customer.vendor.com, and finds a SRV record that says that the server is actually at ts4.vendor.com:1234.

BTW, here's MS' page explaining SRV:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q232025

[ScratchMonkey]

BTW, is there any reason why the UDP and TCP ports are different? Why not make them the same? For instance, DNS uses the same number for both its UDP and TCP ports. Note that these two ranges are separate, so there's no conflict if you use the same number for both purposes.

I was gonna take a look at IANA's port registry to see how one declares one is using a port, so it'll get into the database and allow its inclusion in service name files.

[R. Ludwig]

with ts 2.0, there will be no more tcp...

we do all by udp now..

[N. Werensteijn]

Originally posted by ScratchMonkey
BTW, is there any reason why the UDP and TCP ports are different? Why not make them the same? For instance, DNS uses the same number for both its UDP and TCP ports. Note that these two ranges are separate, so there's no conflict if you use the same number for both purposes.

I was gonna take a look at IANA's port registry to see how one declares one is using a port, so it'll get into the database and allow its inclusion in service name files.
Like ralf said, tcp is no longer needed in ts 2.0

The reason we did not use same ports in ts1, is because win2k (pre sp2) had some issues with udp and tcp open on the same port. (creeping ping)

[ScratchMonkey]

Ick, found an explanation of "creeping ping" here:

http://www.planetunreal.com/TheAdminPage/

I wonder why using the same port number for two different protocols affects this?