Scaling out a Jetlang app - Design q

[Abraham Menacherry]

I am doing an evented game server as a project which uses Jetlang for
its internal in-vm messaging. Below is the normal program flow.

1) I get socket data tcp/udp from clients
2) After going through a bunch of decoders the socket data gets sent
to a player session's onEvent(IEvent event) method.(Events are like
login, logout, data_in etc)
3) Each session has an event dispatcher written in Jetlang, the
session on recieving the event will call the fireEvent method on the
dispatcher, which basically publishes the event to the dispatcher's
MemoryChannel.
3) The dispatcher's fiber will pick up the event and send it to the
SessionEventHandlers based on their event type. datain goes to datain
handler, data out goes to data out handler and so on.
4) The event handlers would contain player and game related
information for e.g. a players current score, life left etc etc.

The question I have is, how do I "scale-out" this architecture? Should
I push my sessions to a data grid (hazelcast, infispan)??. Will it
work? I am asking due to the Event dispatchers connected to the
session and the event handlers connected to the dispatcher.

As a beginning, I would just be satisfied with High Availability,
meaning one machine crashes and the other one would transparently take
over.

The modified work flow would be.
step 1 same as above
step 2 after decoding client data, do a lookup session from the
distributed map and call onEvent on it. -> Is this step practical?
rest of the steps.

Thanks,
Abraham.

[Mike Rettig]

Abraham,

Sorry for the slow response but I've been on vacation.

I don't have any real answers for you. I haven't worked on a gaming
architecture. The implementation details you have provided all sound
reasonable.

http://code.google.com/p/jetlang/wiki/Remoting

Jetlang remoting might be a viable option for a simple distribution
mechanism. It doesn't provide failover, but I've already thought about
how that could be implemented. It already detects disconnects and
automatically reconnects, so I would just have to add some round
robining reconnects. Subscriptions are persistent so the reconnect can
be transparent to the client. Let me know if that is of interest and I
can provide you with a build.

Mike

> --
> You received this message because you are subscribed to the Google Groups "jetlang-dev" group.
> To post to this group, send email to jetla...@googlegroups.com.
> To unsubscribe from this group, send email to jetlang-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/jetlang-dev?hl=en.
>
>

[Abraham Menacherry]

Mike,

Jetlang remoting could definitely be viable. The link for examples on
Remoting are not going through, hence I am unable to check them out
for now.

Thanks,
Abraham.

> > For more options, visit this group athttp://groups.google.com/group/jetlang-dev?hl=en.- Hide quoted text -
>
> - Show quoted text -