[rabbitmq-discuss] Implementation / Specification Stability?

[Landon Fuller]

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  
both incomplete
and imperfect, and I'd appreciate input.

First, an introduction to our problem space. We write reasonably  
large online
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  
state, and
	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
developer, and we'll run their code in a javascript sandbox on  
dedicated machines.

I see the following two abstractions as being most valuable for this  
sort of service building:

	- RPC:
		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
		handled again.

		We can dispatch RPC requests to Java (possibly via a reflective  
dispatcher), JavaScript
		(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
> it.

Thanks for your reply, that provides me with quite a bit more  
confidence.

-landonf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20071019/73aef262/attachment.pgp