Hi,

our live shard has a static IP, but when testing new POL releases
on my home server, I always have to correct the servers.cfg
and enter the current external IP first before booting POL, so that
other people will be able to log onto my shard.

I'm wondering if support for DNS resolution in servers.cfg could be
added, so that POL would resolve that DNS name at least once when booting, and then use the corresponding IP.

I then could use my dyndns address, and wouldn't have to worry
about updating the servers.cfg anymore.

Thanks,
Xandros

Just to clarify, I'm behind a router, so POL can't detect my external IP.

Xandros

Maybe this was taken out but I always used my no-ip address (tribulation.sytes.net) in my servers.cfg. Strange.

Yeah.. its supported host names for me as well. The problem seems to be your machine cant resolve them into an IP.

Actually I never tried it with a hostname. There doesn't seem to be any
documentation about DNS support, the docs only mention IP numbers.
So I presumed there was no support for it.

Xandros

Always resolved hostname for me too. Xan I think there used to be something a few versions ago mentioning hostname resolution buty I thing that line got removed from either the docs or the servers.cfg file comments somewhere along the way. Either that or it was mentioned on one of the incarnations of the POL forums way back sometime.

servers.cfg does indeed support entering a hostname. However, the UO client only accepts IP addresses, so the server will resolve them.

I think it works pretty well as-is, but in a NAT scenerio with dynamic IPs, I think there are two things to help;

First, your NAT device should be set to allow redirection back in from internal connections. I think a lot of people behind NAT fall into this trap, because some NAT devices enable redirection by default, and others don't, so it's not something frequently mentioned. Of course, you could otherwise use a separate servers.cfg entry marked only for your LAN to point to the LAN address, so you don't bother the NAT device with it.

Second, when a dynamic address changes, POL makes no effort to update itself. Of course, it has no way of knowing, as has already been mentioned. So it will keep sending the resolved IP address it got on startup to clients; The client will connect to the login server part, but fail to connect to the game server part, because the login server part is still sending it's old information.

I addressed this issue on our test server, which we have behind our DSL on NAT, with an external program that periodically checks for an IP change. When it detects a change, it does the Dynamic DNS update, of course. Since we've been using 096 for our test server for a while, I used packet hooks to address this. The program noted above also connects to our test/096 server to a simple script I made that sets a global property with an array of the bytes of the IP address. I hooked the 'connect' packet from the server to insert that information instead of what it gets from servers.cfg. The hook I have checks first to see if the connect packet being sent out contains the private LAN ip information; if so, it leaves it alone. If not, it alters the info from the global property.

just use something like DynDNS, let it update by your Router and enter this DNS-entry in your servers.cfg - works fine since years...

Shinigami

My real issue with putting the domain name in servers.cfg was that every now and again dns servers go slow or have issues.

Looking up the dns of the connection runs critical, meaning the whole shard can freeze when the server's dns server is running slow. It happened to me on a couple of occasions and I eventually went back to putting in the ip address.

that's true. in this case, an external program resolving dns in a loop and creating a servers.cfg would be the solution - I think so.

Shinigami

Shini is the servers cfg read in once by POL or does POL refresh from the disc while it is running. If it refreshes then an external program could run alongside POL and update servers.cfg in the event of an IP change.