Frankly, the method name is just a kind of type marker. And if you use async methods, you have a one-way data conduit.
On Mon, Mar 23, 2009 at 6:09 PM, Bryan Duxbury <[email protected]> wrote: > 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; >> } >> > > -- Ted Dunning, CTO DeepDyve 111 West Evelyn Ave. Ste. 202 Sunnyvale, CA 94086 www.deepdyve.com 408-773-0110 ext. 738 858-414-0013 (m) 408-773-0220 (fax)
