 |
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Author |
Message |
Marilla
Joined: 02 Feb 2006
Posts: 329
|
 Posted: Mon Jul 17, 2006 5:13 pm Post subject: |
 |
|
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. |
|
 |
|
|
|
|
|
|
