I don't understand what is hard about using a single method for the
client to call in and report messages and get a set of messages back
at the same time. You can use pseudo-unions to support many message
types, it's already built in to thrift, and it's hyper simple. You
should only use async methods if you don't want to get any messages
back, or plan to query for messages via a separate rpc for some reason.
I personally would avoid two way communication, since you'd run afoul
of firewalls and have to do all the work of hosting a server, which
just seems unnecessary.
-Bryan
On Mar 24, 2009, at 5:38 PM, Ted Dunning wrote:
If you want to send asynchronous messages from server to client,
you should
send asynchronous messages from the server to the client.
That means the roles reverse.
For a real game, this will lead to problems with firewall traversal.
Generally, this is handled in the real world by using some sort of UDP
firewall penetration. See
http://en.wikipedia.org/wiki/Simple_traversal_of_UDP_over_NATs
You could make Thrift work over this protocol, but it will be work.
On Tue, Mar 24, 2009 at 5:01 PM, Doug Daniels
<[email protected]>wrote:
...
The one-to-one message to RPC call Async solution will let a
client send
messages of any given type in my defined protocol, but how would a
server
respond to a client with a message that the client didn't request?
