OK network object is A++ IMO It handles all packet sending and recieving automatically. All the main program has to do is push a packet onto the toBeSent queue when necessary and the object handles the rest. Likewise, the object automatically reveives incoming packets and stores them onto a newPackets queue for the main program to pop from and handle. Now the next step. Clients will be sending packets to me and I push them all onto a generic queue. How to handle them then? Does the main program simply handle them in the order they are received and not take into account who they came from? Or should I farther separate each packet out by sender and handle a packet per sender each round? Right now I''m thinking of the simple pop a packet and handle it no matter what. I will be doing a separate queue for urgent messages but that''s an easy add. So what would the main program have to keep intact for each client? I''m assuming it needs to keep data on each clients current state (standing, running, sitting, zoning, etc)? Or is it a simple "I don''t care" and just let the server examine the packets and handle them as necessary. Willing to bet that I at least need to keep track of most recent client state in order to compare it for cheating. Also, say multiple clients in the world form a "group". They can send chat packets that only go out to their group so I''m assuming that each group would need to have it''s own structure holding the members so that when a person speaks to the group then the chat packet can be sent out to all other players in the group. These would be volatile. But things like persistene groups like guild groups would have to be stored in the database and kept in main memory while the server is running. Just looking for some general pointers I guess. Thanks for any input, Webby

> Or should I farther separate each packet out by sender
> and handle a packet per sender each round?

Receiving should not pose a problem and you can afford to receive and process them in the order they came in. You don''t have much control over the receiving end, _BUT_ you should pay attention to the sending side and serve clients in a round-robin fashion. Clients can''t tell if they use the server''s bandwidth properly (they don''t see other clients) so it''s the server''s problem to distribute its bandwidth efficiently.

> I will be doing a separate queue for urgent messages but that''s an easy add.

Take a look at how ENet (enet.cubik.org) handles reliable and non-reliable packets (read the header in peer.c) and how it handles bandwidth sharing amongst clients. Interesting read.

> So what would the main program have to keep intact for each client?

There is the dynamic state which is position, orientation and stance, what the player is currently holding, etc. which is kept in memory during the simulation. Then there''s the permanent state containing stamina, last safe position, points of all kinds, that you keep in a file database you update when needed.

> Also, say multiple clients in the world form a "group".

I thought about a secondary server for this (just a very wild thought...). Clients would handle the 2 sockets connection, but each server (game simulation, chat traffic) could operate independently. You have an explicit login/password process for chat, which could be different than that of the game. Guilds would ''pay'' for a channel and manage who gets an ID and a password. People do it with IRC informally anyway, so why not have the service integrated in the client and get some $$$ for the convenience this would provide gamers.

-cb

By group I meant an in-game collection of players who say "Hey dewds, let''s go sleight yonder dragoon!" and the 6-35 of them group together for the task. They would want an in-game method to communicate only with other members of their groups.

Exactly like DAoC or Everquest when you form a group.
There would be various channels for different purposes: group, guild, randomChat, out of character, auction, shout, etc.

Having an out of world chat room where players can gather to talk (much like an AOL chat room) would almost certainly be done on another server as the functionality there would be immensely different from the actual game server, login server, etc.

That''s easy to handle. Players joining a specific chat are added to that specific list along with other players. Then route messages accordingly.

However, in the game world, if it''s broken into zones for example, there could be many different groups with players being in multiple groups/channels at a time.

I think it''s going to end up being a simple list of clients and when a client sends a chat to a specific group then the server will recognize this (based on packet type and group reference number) and send it on to only the appropriate players.

Back to packet handling.
Let''s assume that I handle X packets every time through the main game loop. Another thread is handling the reception of incoming packets and stores them onto a queue for later processing. I can
A) have the main loop pop and process a single packet per loop
B) or pop and process multiple (up to a maximum) number per loop.

This would not care who the packets are from, it would simply process the X number of packets at the head of the queue.

I guess which method I take will depend on timing issues. If the loop is fast enough I can handle one at a time, otherwise I might need to set it up to handle multiple packets per pass.

I''ll just run some tests later on and see what happens.

Thanks for the input,
Webby

Planeshift has a group/guild communication feature you could reference (open-source MMORPG). I''ve spent the last week or so going through the code. As with most big projects, it''s brilliant in places and really ugly in others.

They essentially have a Broadcast function (see NetBase.cpp) that sends messages across the wire to multiple clients. The Broadcast function can be passed an optional parameter that determines who will receive the message. I forget the details, but if a constant EVERYONE is used, then all connected clients receive the message. If GROUP is used, then everyone belonging to the same group as the original sender is used. If GUILD is used, only the original sender''s guild is included. etc. etc.

Behind the scenes it just uses an iterator to step through each client, retrieve their information (guild, group, etc.), filter, and then Send_To if appropriate. In your case, this would just be a layer between your chat message handler and your network object. A more elegant solution would be to keep the clients indexed based on these variables so that you don''t have to iterate through each connection.

bpopp (bpopp.net)

> A more elegant solution would be to keep the clients indexed based on
> these variables so that you don''t have to iterate through each connection.

My point was that the client app would be used as a service aggregator, much like your web browser picks up the HTML file from the server you''re linked to and ad banners from another server. You could have one main server for the game itself and the basic chat service based on proximity within the game world''s realm. Guild-specific chat would be an added service using another server that clients would pick up on another socket. You add servers as you add services and you don''t have to keep a per-player table of who has access to what on the main game server. IMHO, this is probably more scalable than having one server handle every possible service under the sun. But then again, that was a wild idea to begin with...

-cb

Hmmmm
I think you might have something good there CB
Have the world server do nothing but communicate information related to the actual game (monsters, movements, death, inventory changes, etc). Have a separate server on it''s own socket that handles nothing but chat packets based on groups (broadcast, everyone in group, everyone in guild, everyone in OOC chat, etc)

Then the world server could more focus on important tasks (managing the world) and the chat server could do that also.
It is conceivable that only one or two machines would suffice for all chat services. I don''t think a few thousand (hopefully) people will be able to talk fast enough to bog down the server.

Then as you stated, if I add more options later then it''s a matter of drawing up a new server codeset to handle those options and voila, nothing needs changing on the existing servers and on the clients where all options run on a single machine I can still treat the parts as different clients and update them as individual units as opposed to altering one large code base.

Brilliant idea. Now the game server doesn''t need to keep track of anything other than a global list of active clients. Of course this can be subdivided to isolate clients by region of game to make client location faster but given only a few thousand max per server I think that the network will become the bottleneck LOOOONG before traversing a list will.

This is something I plan to start diagramming this week and hopefully beginning a base implementation of the following week. It is likely that I will draw up a rudimentary GUI and work on the chat server first of all as that will undoubetedly be the easiest to get up and running and will alow me to take some metrics to use on the world systems.

Thanks for the input. It hadn''t occurred to me that "ohh yeah" I can run multiple types of servers besides just a login and world server even on the client machines.
Thanks,
Webby