Okay, so that's the way I had it theoretically figured out. I was just hesitant to think about 50 levels loaded in 50 server-applications at the same time on one single machine.

Also I might have to use a more hands-on approach apart from your entity-function-set. The thing is, that I don't want to terminate and reconnect each time a zone change occurs. Therefore I have to have a persistent connection throughout each session. Below you'll find my first concept of the server structure.



After authentication (grey arrow) the authserver appoints a session server (of which there could be many) considering the amount of players already on a session server. He then tells the session server to expect a new client and tells the client on which session server to connect (red arrows).

After the connection is established, the session server queries the database server for the last known position and other information (playerstats and such). Then it queries the level management server for the level which might end up in the player being placed in this level or forced to another one if the player is in an area that doesnt exist anymore.

To put things short: All actions are routed through the session server so I don't think entity updates from a level server can be easily handed forward directly to the client. From what I gather I have to do this manually. Reconnection according to this layout is out of the question, because I would have to re-authenticate every user on a zone switch and the connection to the chat server would be lost.

On a sidenote: From my experience your ANET-Lib is really good. I thought about doing one myself using RakNet, but why reinvent the wheel. I'm still in the process of evaluation, but if ANet fulfills all needs, you can expect a paypal payment soon. :-)