Vanilla Netrek Server Development Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[VANILLA-L:907] Metaserver

I recall several years back, probably like 1994 or so when Chico state was having some bandwidth problems and we frequently could not connect to the metaserver as a result inquiring about setting up a second metaserver.

 The issue at the time from Nick was the load that having multiple metaservers would place on the netrek servers.  Which made sense at the time as a typical server was run on say a Sparc 2 or DECstation 5000 with maybe 48-64 MB of RAM.  These machines didn't have much processing power, the harddrives weren't that fast, etc.

 And the way the metaserver is implemented, it queries the server by telneting to the players port, which spawns a process and returns results.  This is inefficient.


 What about a different solution for a metaserver?

 What if instead of the metaserver querying the servers, it worked the other way around.  A small process sits on the server which periodically sends information regarding itself to the metaserver?

 I guess the benefit of this is two-fold:
 1. A more efficient solution, it would be written specifically for this task, rather than the metaserver taking advantage of a feature never intended to be used in that manner.
 2. It would allow for a dynamic metaserver.  A server could come up, advertise itself with the metaserver without intervention on the part of the metaserver operator.

 There could be multiple metaservers as backup.  The Netrek server side would try to send the same information to multiple servers, the client could query these either through a round-robin DNS, or a fallback behavior on the client.  Obviously some method of load balancing would be necessary.

 Another benefit that I can see, is that this could be leveraged into a clue-pickup metaserver.  INL servers could register themselves with a totally different metaserver, clients could be pointed to this metaserver.  A calendar of registered clue games could be integrated into this.


 Is this a good line of reasoning to investigate?  What are other peoples thoughts?

 This would involve some signifigant coding from a server side.  I think the client side piece could be made backwards compatible, with a newer interface for new clients.

Steve
 
+
++ Vanilla-l Mailing List ++
To unsubscribe: send "unsubscribe vanilla-l" to majordomo@real-time.com
For more information: http://archives.real-time.com
Follow-Ups: