same JVM. a) this makes a good example of self-hosted style
LAN multiplayer games, and b) it causes the serialization bug
to show up so I can fix it. (Already fixed it and that commit
will be next... it's almost like TDD.)
registration set to each new client that connects. The
client-side version of this service will then register them
all. This means that serialized classes need only be registered
on the server.
I've modified DefaultClient and DefaultServer to register these
services by default because they make other services easier to
write and because they will save people lots of trouble.
I'm 90% sure there are no bad side-effects for people who choose
to continue doing things the old way but it may depend on when
they register their serializers in relations to creating the
client and server objects.
with custom subclasses and service interfaces for client
services and server-side services (HostedServices).
This code is a copy and refactoring of code I developed for
Mythruna... it worked there but I haven't tested it yet in its
new form. Things may change as I integrate this more closely
with the core Client and Server classes. I wanted to get it
into source control first.
Also included an RPC service implementation which can serve
as the underpinning for other things.
Coming soon: serializer registration service and a simple
RMI service based on the RPC layer.
* Formatting for com.jme3.effect package
* Formatting for blender importer and networking tests
* All networking tests ported to new SpiderMonkey
* Removed all mentions of java.util.Serializable
* RMI now works under new SpiderMonkey
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7593 75d07b2b-3a1a-0410-a2c5-0572b91ccdca