What is the kind of game you will be running?

It's a tcg/ccg action game. It's not a 3d seamless world, but rather lots of small "pvp like" battles. It's not really player-hosted either as the games will be "played out" on the server for authoritative decisions with the clients just sending input, but yes, there will be a matchmaking service. Also, I have plans that this server architecture/design will be helpful in more than just this project.

I have lots of ideas now on how to go about this so thanks everyone for getting the wheels turning!

Now, is it feasible to have the game servers connect to the chat server? So the client could send a message to the game server with chat information and the game server sends that along to the chat server rather than having the client handle the separate game/chat connections.

There's nothing wrong with having multiple connections from the client to various back-end components. In this case, you're going to have two separate connections, one for the game server, and another for the chat server. When a game server starts up, it sends a request to the chat server to create a new channel (a privileged operation not available to clients). When clients join the game server, they're told to join the previously created channel. Likewise, when a client leaves the game server, they're kicked from the chat channel. When the game server shuts down, it destroys the channel and all the remaining clients get kicked.

You don't have to restrict chat to game servers, either. You can have a chat channel for players looking for games from the "main" server, one for each guild (if your game supports that), one for people who need technical support, etc. Once you decouple chat functionality from game functionality, the possibilities expand tremendously.

I would favor having the client connect to the chat server and the game server rather than have the game server redirect to the chat server.

You want to cut down on the total number of sockets that will be open on the servers at all times (use only bare minimum # of open connections to achieve desired result).

You can even have game servers, and then have zone servers that belong to the game server but handle things like hit detection, combat, etc at the local level where the game server just keeps up with what zone you are in and your inventory, etc.

The client could simply just open a connection to all necessary servers.

The login server would tell the client which game server to connect to. The game server would tell the client which zone server to connect to based upon stored player position data.

Thanks for the information everyone!

I am currently well on my way of starting a shared framework for the servers. This will make it easy so that I just have to reference the library and supply an IP and Port to open up a listener to connect to. The first server I am working on is the login server. The plan is to have a direct connection to the database rather than go through a database server. It'll allow account creation and logging in. After a successful login, it will send the client a message to connect to the main server (which I'll work on after the login).

I'm also currently working up another shared framework that both the servers and clients use. This houses all the network aspects (connections, reading, and writing). So, using this, the client will connect to the login server IP first, and after receiving a successful login message, will reconnect to the main server. The framework makes it easy to pass in an IP and Port to handle all the work. The client can then listen for incoming messages or send messages to the server using the framework.

I would like to reiterate that this is not an MMO project or anything on a huge scale. The idea is to just build up the servers so they can be scalable, whether adding or removing to balance out the players that are connected.