thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Terry Jones <te...@jon.es>
Subject Re: Using thrift as part of a game network protocol
Date Fri, 03 Apr 2009 09:16:39 GMT
>>>>> "Ted" == Ted Dunning <ted.dunning@gmail.com> writes:

Ted> That is, could there actually be a fully operational Thrift transport
Ted> that moves requests both ways on a single socket?  You would give it
Ted> something that implements the server interface and it would give you
Ted> back something that also implements the interface.  You could call it
Ted> and it could call you in horrifically complicated but very cool ways.

Right. I had the same thought, in this form:

You could take a normal Thrift service spec and essentially produce two
services from it. A server method that returned an X would become an async
server method, and a (client-side) server method that took an X as an
argument would be generated to run on the client to receive the method
result as originally intended.  You would need something under the covers
to keep track of the outstanding calls and match them up with their
incoming async results (if any).

It would begin to look something like the Twisted/Thrift solution, which
conceptually already does this (with the help of Twisted's deferreds and a
client-side dictionary of outstanding requests).

The two are NOT exactly the same, just quite similar. As Doug said
originally:

>> you'd have make sure you don't "miss" sending a client a message if they
>> finished their Async call but haven't reestablished a new one.

But, to show a bit more similarity, Joel pointed out that his suggestion
allows the client to immediately know when the server has gone away. You
can do this already with the Twisted/Thrift combination: the client makes a
Thrift method call, say adviseOnShutdown, and immediately gets back a
deferred.  That pending call just sits there client-side (the caller and
the Twisted/Thrift code both have a reference to the Deferred) until the
server either actively returns to indicate that it's going away, or
disappears, in which case the client gets the disconnect as a failure from
the pending deferred.

I hope the above all makes some sense!

Terry

Mime
View raw message