thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Duxbury <br...@rapleaf.com>
Subject Re: Using thrift as part of a game network protocol
Date Tue, 24 Mar 2009 01:09:52 GMT
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;
> }


Mime
View raw message