Michael Toennies wrote: > Isn't it easier to let the metaserver "ping" the servers all 5-10 minutes? > If he don't get x times in a row no contact, the meta drop the server. > > This makes the list very up to date and the server must report only one time > (when he starts) to the meta. The servers have to contact the metaserver at least at some point. If I set up a server, the metaserver has no idea it exists. The bandwidth for the server to send updated information every 5-10 minutes is minimal. Plus, the server has to notify the metaserver of any updated information (number of players for example). This is also less dangerous in terms of attacks against the metaserver. Yes, you can still send thousands of packets to the metaserver, put that is the case now. If the metaserver actually keeps pinging the servers, a malicous person could set it up to register thousands of servers to the metaserver, and the metaserver is now sending lots of packets out to try and contact that. Plus, the servers out there still need to respond so that the metaserver knows they are alive. Much eaiser for the servers to just send the pings to the metaserver, and the metaserver doesn't need to respond then. > What also is urgent needed, mainly for new players, is a value for the > connection speed - from her client side of course! This has to be done purely on the client. If for example the metaserver is located in northern california, it would probably show very good connect speed to the berkely server for example. But that data is completely useless if you are in germany, since the lag is actually getting the packet to the metaserver. And due to how the internet is routed, you can get situations like: metaserver hosted off one major carrier. server and client hosted off another major carrier, but the same one. Communication between the two major carriers is bad, so times from the metaserver to the server are not good, nor are times from the client to the metaserver. But times from the client and server are just peachy keen. This can especially be true for example if the client and server are actually on the same LAN, and its the connection out of that LAN which is slow. So it is up to the client to verify this speed. Note that it would not necessarily be hard to do. You could just time the transmission of some of the protocol setup (Exchange of client revisions for example). This is probably more accurate than just a ping, since this requires actual server interaction, which would be slower if the system has a high cpu load or is swapping like crazy - things you would care about, but which ping would not show. It would actually be easy enough to add a PING command to the protocol, but I'm not sure how much that would add to the server. The disadvantage with this is that it does impose load on the server and client (to setup the connection and tear it down to then present the results to the player). The problem is that there are problems of scalability. If you have 100 servers (hypothetically), determining the speed of all those could literaly take a few minutes. Perhaps in that case, you select a few which you think might be near by (based on description of hostname), and ping those to see which is best? Similary, if you said had thousands of players with all those servers, there could be a decent amount of load caused by all those connections (to see lag), even if only 10-20 people are per server. But that is probably getting ahead of myself. And realistically, you can't prevent that - if a client really wants to get the most accurate timing information, it could do the connection and protocol exchange, and there is really no way to prevent that (as the clients are open source).