javaspaces

[aNt]

what about using javaspaces for handling mmpo worlds?
or is it best to use a 'simulation' and wrap all your own
calls over tcp/ip etc...

just 'take', 'write' etc seems very neat- maybe it hasnt
got the speed needed for mmpo?

just intrested in peoples thoughts.

[abies]

There was a bit of discussion about this subject lately at mud-dev

http://www.kanga.nu/archives/MUD-Dev-L/2004Q3/msg00704.php

[blahblahblahh]

J C Lawrence wrote:

>Are tuplespaces interesting for game >development?  What would be
>needed to make them more interesting?

(I wrote...)

IIRC they're already being used in game development, under that
guise - I thought that IBM's grid computing used ts's extensively,
and Butterfly is an IBM grid...as is PS3 (IIRC?).[1]

FYI, we use the similar concept of unbound message-queues [2] a lot
in the execution layer.
...
I find tuplespaces far too abstract to be tenable in real-world
programming with real-world programmers who don't have phd's in CS
and have never heard of ts's nor probably want to. Unbound MQ's seem
to be a lot easier for today's typical programmer to get to grips
with, perhaps because they are a clear logical extension of a
paradigm that most programmers are very comfortable with
already
...
FWIW, I'm currently looking at whether we'd solve
some of our
problems by binding more of those MQ's [3]...there are considerable
late-in-development-cycle problems that occur where your structure
is too implicit and not easily reasoned about offline.

The basic concept is almost essential to writing good semi-infinitely scalable systems.

But games developers don't tend to like it much...

Games published by our own members! Check 'em out!

[aNt]

so no ones tryed it? it looks like javaspaces is just a
wrapped up RMI- and that seems abit over the top
for tracking game object?

[jherber]

i've used jini and javaspaces to build a highly scalable service oriented architecture for bioinformatic services.   the architecture is very ripe for mmpog:  distributed transactions,  naming services, leasing services, and javaspaces.

i have zero experience with mmpog architectures and can only base my opinion on my own experience building discrete event simulators and soa architectures, but, i think the technology is a fit.

in mmpog's i believe the key is in grouping objects based on probablity of interaction, proximity, state of an entity, or a network of interactions among entities.   these obvious partitions are implemented via javaspaces.   operations on the group or individuals is implemented as a jini service.  attributes of the object are implemented as a java class.  

[blahblahblahh]

so no ones tryed it? it looks like javaspaces is just a
wrapped up RMI- and that seems abit over the top
for tracking game object?

Not by a long way! Tuplespaces (as it's more rightly known) is completely unrelated to RMI, architecturally.

Anyway, as the above quote shows, we're using tuplespaces (albeit in a different guise - free-floating MQ's). We have considered doing a javaspaces wrapped implementation of some of our tuplespace stuff to see how it compares to the current implementations, but as far as I know no-one here has used it in anger...

PS copy/paste misattributed that quote - I'm about to fix it

[blahblahblahh]

in mmpog's i believe the key is in grouping objects based on probablity of interaction, proximity, state of an entity, or a network of interactions among entities.  

From experience, those groupings are relatively unhelpful in any large scale MMOG. You have to use tuplespaces at a more abstracted level in order to reap the rewards (high degrees of parallelism etc)

[aNt]

just i read this someplace:

Sun took many of the ideas behind the Linda system
and adapted them to their Java environment. The
adopted Java as the implementation language. This
provided platform independence and the ability to
execute objects on remote machines through the Java
Remote Method Invocation (RMI).

i would love to get me head around this.. sounds very
interesting stuff. im making a simulation that has lots of
object and i was thinking this maybe the way to go.
there will also be lots of connections (players) interacting
with the objects in the space in realtime.

[jherber]

look in your local bookstore for this book:  http://www.amazon.com/exec/obidos/tg/detail/-/0201309556/104-2050770-3847115?v=glance  it will plant the seeds...

[jherber]

From experience, those groupings are relatively unhelpful in any large scale MMOG. You have to use tuplespaces at a more abstracted level in order to reap the rewards (high degrees of parallelism etc)

can you elaborate?  don't you use tuples to represent the state of a player or entity in the world, and a tuplespace as a set of related entities?

Games published by our own members! Check 'em out!

[jherber]

Not by a long way! Tuplespaces (as it's more rightly known) is completely unrelated to RMI, architecturally.

sun's implementation of jini/javaspaces is tightly coupled to rmi.  all the core services are constructed as rmi activatable services (reggie, ma.  all javaspace objects must be rmi friendly (serializable).  if you build any user services to interact with a javaspace out of process or in a distributed fashion, you will use rmi.  in sung li's jini book he spends a few chapters getting those not up to date on all facets of rmi up to date.

i think jini/avaspaces is much more than the original tuplespace in that a javaspace contains objects with methods and i think the original definition of a tuple is just data.  jini also provides a plethora of services for architecting distributed solutions:  leasing management, discovery/lookup, distributed transaction management, distributed events.  i'm not sure that gelertner's original concept provided such a complete set of building blocks.

[blahblahblahh]

sun's implementation of jini/javaspaces is tightly coupled to rmi.

Sure, but my point is that the two are entirely different things, not (as the OP questioned) simply minor extensions of each other.

Tuplespaces are an alternative programming paradigm.

[/quote]
i think jini/avaspaces is much more than the original tuplespace in that a javaspace contains objects with methods and i think the original definition of a tuple is just data.  jini also provides a plethora of services for architecting distributed solutions:  leasing management, discovery/lookup, distributed transaction management, distributed events.  i'm not sure that gelertner's original concept provided such a complete set of building blocks.[/quote]

Well, objects with methods ARE just data in the java world. I'm not really comparing to whatever the original CL/linda roots were, but what people have spent the last X years using as the generic concept + programming paradigm of TS's. I've only used javaspaces having already known TS's and not noticed any differences (yet).

Sure, the JINI services are useful, but are they an intrinsic part of javaspaces (both are available as separate downloads, aren't they?).

[blahblahblahh]

can you elaborate?  don't you use tuples to represent the state of a player or entity in the world, and a tuplespace as a set of related entities?

That's not a trivial question to answer, and the going rate for consultantcy on this is $85/hour...

Grexengine.com is being redesigned at the moment now that some of the patents have been granted. The new content may include an article on this, because it's an interesting set of problems. Could be a while though, I'm afraid.

[aNt]

hahaha blabla'''' - heres somthing for u that confuses
me- wonder if u could wave the $85 i got like a rubber
band and some old fluff in me pocket if u want that ?

anyways... heres what makes me abit confused...

if we make a game with javaspaces the objects are
serialized and stored yes?

then say we have a house class. then the database will
have loads of serialized house instances.

if we update the house class because of a bug ;-) then
what happens to all the old serialized house instances
stored in places all over the network...

[jherber]

anyways... heres what makes me abit confused...

if we make a game with javaspaces the objects are
serialized and stored yes?

then say we have a house class. then the database will
have loads of serialized house instances.

if we update the house class because of a bug ;-) then
what happens to all the old serialized house instances
stored in places all over the network...

depend what you modified in the class and whether you include a constant serial version in your class.

now, replacing this house dynamically without shutting down the jvm is a complete different problem that requires more abstraction, registration, versioning metadata, etc...

[jherber]

(both are available as separate downloads, aren't they?).

nope... javaspaces are just one service in jini.

[jherber]

That's not a trivial question to answer, and the going rate for consultantcy on this is $85/hour...

fair enough blahblahblah, but  intuitively it seams very easy to map the mmpog framework requirements directly onto jini or a jini-like framework.   sounds like fun stuff...

[blahblahblahh]

fair enough blahblahblah, but  intuitively it seams very easy to map the mmpog framework requirements directly onto jini or a jini-like framework.   sounds like fun stuff...

Sure, it's intuitive. But intuitive != effective. Most complex systems don't work if you merely try to fit them into an arrangement that is conceptually obvious and sensible to a human - instead you usually have to find what is convenient and efficient for the hardware and software platform.

NB I'm not trying to be patronising (I'm sure you know this already), just trying to make clear what I mean by saying you can't just do what would seem sensible.

[jherber]

NB I'm not trying to be patronising (I'm sure you know this already), just trying to make clear what I mean by saying you can't just do what would seem sensible.

agreed :>  ...further, until you've created such a beast it is just an academic exercise at best, but fun nontheless.

[the2bears]

sun's implementation of jini/javaspaces is tightly coupled to rmi...

They were, up to Jini 1.2 but after that RMI was just one of a few pluggable transport layers.  JERI is the reworked and rethought replacement for RMI.

I and my company, Kayak Interactive, and it's predecessor have worked with Jini for over 4 years now - pretty much since the beginning.  Funny coincidence, Jini and multiplayer games:)

Bill

[jherber]

They were, up to Jini 1.2 but after that RMI was just one of a few pluggable transport layers.  JERI is the reworked and rethought replacement for RMI.

wow!  that's about when i finished up my jini project.  how do they handle something like:  invoking a network tranparent object?  rmi's activation functionality?  did they ever add a security model?  

[aNt]

JERI supports the standard RMI semantics but is
designed to be more flexible than existing RMI
implementations such as JRMP and RMI-over-IIOP.
It can support:

-The new Jini trust model
-Elimination of the compile-time generation of stubs
-Non-TCP transports
-More flexible distributed garbage collection
-Much greater customisation