This looks similar to the problem I’ve been chewing on (& had some good feedback from Jeff in another thread).
I assume your game server opens a connection to the servlet to inform it of it’s existence. The servlet can then tell users all the servers that have registered with it.
If I got the above right, then the server (when behind a router) needs to open a known port on the router so as to be able to accept incoming connections from perspective clients. This either means port forwarding on the router (in which case you have a known port open on the router to accept incoming connections), or you can use UDP punchthrough. UDP punchthrough avoids manual port forwarding, but does need an Introducer application running at a known address to make the concept work.
My (buggy) Introducer listens on a known UDP port. Prospective clients send a packet to this port and are sent in turn a list of other clients that recently talked to the port (I’m doing peer-peer hopefully). However the Introducer could just as easily return a list of servers - The packet sent to the introducer just needs to identify whether it is a server or client request. Servers (run on home computers, possibly with routers) send a packet to the Introducer to register. The UDP port on the router is held open to allow the Introducer to reply. However you can send to that port from anywhere on the net & it will route though to the server. This is UDP punchthrough. Since the Introducer knows what this port is, and can give it to prospective clients, the problem is solved.
NB. The server needs to ping the Introducer at regular intervals (1Hz?) to i) Keep the UDP routing alive in the router, ii) Keep the listing alive in the Introducer.
NB. I have this sort of working, but haven’t tried it through a router yet to see if the UDP punchthrough actually works (meaning whether I have understood & coded it right)
Not sure whether this answers your query. Sorry if I’ve totally missed the point 
Alan
