[rabbitmq-discuss] Implementation / Specification Stability?
landonf at threerings.net
Sat Oct 20 00:52:34 BST 2007
On Oct 19, 2007, at 8:37 AM, Alexis Richardson wrote:
> Hi Landon
> Welcome to the list. Thanks for your questions and sorry for being
> slow to reply.
Thanks! That was pretty quick =)
> On 10/19/07, Landon Fuller <landonf at threerings.net> wrote:
>> I'm investigating using AMQP and RabbitMQ as our service
>> infrastructure backbone.
> Great! Please tell us more - several other people have reported
> similar use cases and getting them discussed on this list is an
> excellent way for community members to benefit from each other's ideas
> and work.
Sure. Hope this isn't too verbose -- I'll throw this out there, with
the caveat that
this is a rough explanation of my current thinking, I'm sure it's
and imperfect, and I'd appreciate input.
First, an introduction to our problem space. We write reasonably
multiplayer games, using Java. All our games implement some variation
of the "place" model:
Within the game, there is the notion of a 'place', and your client
is in it.
A place could be a room, or a pirate ship, or a 10x10 grid of a larger
virtual world. Each place is responsible for maintaining its own
allowing clients to permute the state of that place.
A client may be in several places at once: you could be playing a
puzzle (place A) while you're also aboard a pirate ship (place B).
In my ideal universe, I view places as a service, instances of which
can be started on any server
in a cluster. I'd like implementing these services to be as easy as
possible, with most of the
complexity hidden from the game developer. In some instances, the end-
user may be a game
I see the following two abstractions as being most valuable for this
sort of service building:
RPC services use a request queue, and per-client response queues.
Any number of providers
can attach to the request queue and respond to requests -- that's
an application level detail.
Service providers can detach from a queue, and requests simply
queue up until they can be
We can dispatch RPC requests to Java (possibly via a reflective
(via Rhino), or another server/language entirely.
Incoming requests can arrive via AMPQ, or external RPC brokers,
such as services implementing
XML-RPC, JSON-RPC, Hessian -- etc.
- Data queue:
Very simple queue API for providing events/data to the RPC clients.
An RPC service can place
data in the queue for client consumption. This can be used to
provide data to simple polling clients,
without requiring long-blocking server-side RPC threads. This is
also a prime candidate for wrapping
with a HTTP REST interface.
"Place" is only the first step. We also need banking, currency
exchanges, chat & presence (eg, jabber),
event logging services (for tracking server & user behavior); I'm
hoping these abstractions are a good
foundation towards building those services out.
The above is actually what I've started working on now. In addition
to the groundwork , I also expect to
solve issues like handling service lookups / request routing.
> No you are not shooting yourself in the foot at all :-)
> We have production users today who (as I understand it) are happy with
> 0-8, and are happy with the upgrade path should they need to follow
Thanks for your reply, that provides me with quite a bit more
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20071019/73aef262/attachment.pgp
More information about the rabbitmq-discuss