client/server event protocol

[kjkrum]

This is kind of a broad question, as I'm really not sure how to approach this problem.

I'm writing a game. I need to develop some sort of client-server event protocol. For example, the server might transmit an event to the client that contains the following information: timestamp, event type, source player uuid, target player uuid, and a variable (but specific to the event type) number of parameters.

I'm looking for a way to generate and parse these events that allows as much type safety as possible. I considered creating an enum of all my event types, and then putting code in switch statements (see here) to validate the number and type of the parameters and do something with the data. But gigantic switch statements are ugly, so I'm looking for a better design pattern.

The transport protocol doesn't matter... XML, binary, delimited plain text, whatever. I don't care as long as the event generation and parsing are easy.

[kjkrum]

Sooo... I was overthinking this because I've always read that creating large numbers of objects is bad and should be avoided. But yesterday I found an article that was more specific about what they mean by "large numbers" of objects. Apparently this was a problem on ancient hardware (Pentium II class) with old JVMs (like 1.2) creating upwards of 100,000 objects per second.

I don't know how many event messages my program will generate, but I'm pretty sure it won't be anywhere near 100K/second. So I'm just going to create a hierarchy of event classes and encapsulate each message with type-safe constructors and maybe some handy fromString/toString (or fromBytes/toBytes) methods.

[kjkrum]

Do you know anything about how the performance of a switch compares to dereferencing several objects in a tree? That is, at what point does the tree become more efficient than the switch?

For now, I'm focusing on rapid development. I'll get bogged down in this if I try to optimize too much. But thanks for the suggestion -- I'll definitely keep that pattern in mind.