I am not sure, if this is the right category, but I am curious about how often OpennTTD advertizes itself to the serverlist. It seems to do this only once. Does then the serverlist-server queries all clients? And how is the removal of offline servers handled?
Currently when implementing the online function for simutrans, we are discussing about sending to list server after each join/lost of clinet and purge servers after 24h. However, I would be glad to hear something from the experience from the OpenTTD team.
How often does a server advertize itself?
Moderator: OpenTTD Developers
How often does a server advertize itself?
I like to look at great maps and see how things flow. A little like a finished model railway, but it is evolving and actually never finished. http://www.simutrans.com
Re: How often does a server advertize itself?
A server advertises itself to the master server every 15 minutes and does 3 tries to advertise with 9 seconds in between.
The master server tries to connect to the server before adding it to the server. For this it tries 3 times with 5 second intervals. Upon a reply from the server it will send an "ack, you're registered" packet back to the server.
Then there's a third component, in OpenTTD called the updater. This runs next to the master server and queries the servers every 5 minutes to get the data for servers.openttd.org. These queries are a bit more lenient; it does 5 tries to get the data. If after for 4 of these 5 minute cycles a server does not respond it is marked offline, so after 20 minutes of not replying to the updated you're marked offline.
A server sends a packet to the master server to tell it goes offline, but doesn't retry or anything. That's what the updater is for.
In OpenTTD's system there is no contact from the clients to the updater and only to the master server for requesting the list of servers. The data you see in the server list is all coming from the servers.
Another thing to think about are servers advertising multiple IPs, be it different IPv4 addresses or an IPv4 and IPv6 address (you're better of adding IPv4 and IPv6 support from the beginning and with separated stacks, thus supporting binding to multiple addresses as well). In this case you want them to occupy the same slot in the server list. To accomplish this the master server sends out (pseudo) random unique keys to servers upon advertising; the first advertisement attempt happens with unique key 0 and the master server replies immediately with the key. When the server receives that key it will send another advertisement with that key. The server will retain the first key that it receives and the master server doesn't store anything when it receives a "request" for a unique key.
For old OpenTTDs that don't support this unique key system we use the IP+port as unique ID, but that won't quite work with IPv6 or servers advertising on multiple ports though that doesn't matter for the old OpenTTDs as they did not support binding to multiple addresses/ports.
See e.g. http://www.openttd.org/en/server/33154 for a server with both an IPv4 and IPv6 address (it might be gone when you look at it though).
You might want to take a look at /trunk/src/network/network_udp* and /extra/msu for more inspiration. The msu directory also contains the SQL database design and a small piece about the initial requirements and design for both the master server and updater. Personally I'd make the masterserver and updater separated processes as well. Primarily because the updater would be working with data coming from the server for your server list and as such it's slightly more "vulnerable". It also makes it easier to take down the updater for "maintaince", e.g. an update to the protocol used to send the server information around, while the servers can still advertise and the clients can still get a server list.
The master server tries to connect to the server before adding it to the server. For this it tries 3 times with 5 second intervals. Upon a reply from the server it will send an "ack, you're registered" packet back to the server.
Then there's a third component, in OpenTTD called the updater. This runs next to the master server and queries the servers every 5 minutes to get the data for servers.openttd.org. These queries are a bit more lenient; it does 5 tries to get the data. If after for 4 of these 5 minute cycles a server does not respond it is marked offline, so after 20 minutes of not replying to the updated you're marked offline.
A server sends a packet to the master server to tell it goes offline, but doesn't retry or anything. That's what the updater is for.
In OpenTTD's system there is no contact from the clients to the updater and only to the master server for requesting the list of servers. The data you see in the server list is all coming from the servers.
Another thing to think about are servers advertising multiple IPs, be it different IPv4 addresses or an IPv4 and IPv6 address (you're better of adding IPv4 and IPv6 support from the beginning and with separated stacks, thus supporting binding to multiple addresses as well). In this case you want them to occupy the same slot in the server list. To accomplish this the master server sends out (pseudo) random unique keys to servers upon advertising; the first advertisement attempt happens with unique key 0 and the master server replies immediately with the key. When the server receives that key it will send another advertisement with that key. The server will retain the first key that it receives and the master server doesn't store anything when it receives a "request" for a unique key.
For old OpenTTDs that don't support this unique key system we use the IP+port as unique ID, but that won't quite work with IPv6 or servers advertising on multiple ports though that doesn't matter for the old OpenTTDs as they did not support binding to multiple addresses/ports.
See e.g. http://www.openttd.org/en/server/33154 for a server with both an IPv4 and IPv6 address (it might be gone when you look at it though).
You might want to take a look at /trunk/src/network/network_udp* and /extra/msu for more inspiration. The msu directory also contains the SQL database design and a small piece about the initial requirements and design for both the master server and updater. Personally I'd make the masterserver and updater separated processes as well. Primarily because the updater would be working with data coming from the server for your server list and as such it's slightly more "vulnerable". It also makes it easier to take down the updater for "maintaince", e.g. an update to the protocol used to send the server information around, while the servers can still advertise and the clients can still get a server list.
Re: How often does a server advertize itself?
It seems an ID is really a clever idea (my serverlist guy suggested the same) [Also it seems I have to did deeper in IP6 vs. 4 ...]
Thank you very much.
Thank you very much.
I like to look at great maps and see how things flow. A little like a finished model railway, but it is evolving and actually never finished. http://www.simutrans.com
Who is online
Users browsing this forum: No registered users and 26 guests