It's easy to receive "any" message type. I assume that you actually
mean that you'll have a limited set of known, predefined message
types, and you just want to call one method in order to send the
messages. To do that, you have:
struct MessageTypeA {
...
}
struct MessageTypeB {
...
}
struct MessageBase {
required i32 message_type;
optional MessageTypeA message_type_a;
optional MessageTypeB message_type_b;
...
}
Then, you make message_type correspond to the field id of the message
subtype that's actually set. The rest of the message type fields are
unset. It's a union of sorts.
As far as callback rpcs, I think you're on the right path with having
the clients poll for messages.
-Bryan
On Mar 22, 2009, at 10:54 PM, Doug Daniels wrote:
I've been looking at Thrift and (Google's protocol buffers), trying
to find
a good IDL to build efficient game network protocols (For iphone/
android as
well as regular PC applications).
One thing I haven't found yet when reading about Thrift is that
there does
not seem to be an obvious way to let you receive any type of
message in your
protocol it seems to all be based on writing services and using RPC
calls.
I'm looking for a way to write a more streaming, message based
protocol
where a message comes in off the wire (identified by a message ID)
and you
then know the type of message to read off the wire. This would work
nicely
in a client/server game architecture because the types of messages you
receive could vary so you couldn't always make a call to some RPC like
getGameState(). Also is there such a concept as reverse RPC calls
in thrift
where the server could call on the client (I guess the client would
have to
make some request like pollForMessages() and the response would
have to be
an arbitrary message routed to the client's reverse RPC call).
Most client to server interactions could be modeled as RPC calls,
but the
trouble is not all game server to client messages could be modeled
as RPC
responses (how do I notify client A when client B tells the server
that B
has moved x=2, y=4).
In the Thrift whitepaper it does say that you could implement your own
TProcessor that simply streams a certain type of message and not do
any RPC
binding, the trouble is, is there a way to stream and read a set of
messages
defined as your game protocol, and can you do this on the client
side and
not just the server side?
Maybe I'm fundamentally mangling the concept of RPC or what Thrift is
supposed to be used for, but one solution I came up for doing this
type of
network protocol using Google's protocol buffers was to use
optional message
fields and define a single GameProtocolMessage object containing every
message your protocol defines as an optional field. For example:
http://groups.google.com/group/protobuf/browse_thread/thread/
c2b514f50554c910/e41d25e218161988
message GameProtocolMessage {
optional Attack attack = 3;
optional DamageEntityReceived damageEntity = 4;
optional MoveEntity moveEntity = 6;
}
message Attack {
required int32 targetEntityId = 1;
}
message DamageEntityReceived {
required int32 hpLost = 1;
required int32 targetEntityId = 2;
optional int32 sourceEntityId = 3;
}
message Vector2f {
optional float x = 1 [default = 0.0];
optional float y = 2 [default = 0.0];
}
message MoveEntity {
required int32 targetEntityId = 1;
required Vector2f location = 2;
}
