With the "optional" message field solution is there a penalty for having a large protocol (many messages) defined as optional or does thrift just ignore those fields when sending it to/from the transport?
I haven't looked into the RPC implementation in thrift much but I wonder if I could just dissect the RPC mechanism and use it to keep open a streaming client/server connection. >From what I understand the RPC mechanism passes a string to identify the RPC call which will allow the server to know what message parameters to parse. Could I simply extend that and create a one to one mapping between message type and "RPC" name and have it stream in an arbitrary number of messages given a list of available protocol messages. Also on the client side I was thinking I could do a reverse "RPC" by having the server send 'MessageType" followed by message payload back to the clients, and instead of a regular RPC call stopping once the parameters are read or response written we could continue to stream on the input and output socket streams. Am I over complicating things, I did read that the Thrift protocol messages are self-describing does that mean i don't even need to pass any of this "MessageType" parameters before hand. Maybe it's time to do some code digging, I'm going to create a simple Java server and client and step through the RPC code to see if I can bend it to do what I want. On Mon, Mar 23, 2009 at 8:50 PM, Ted Dunning <[email protected]> wrote: > 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) >
