and ClientRegistrationMessage so that they have fixed IDs
and registration-independent implementations. This means
that no matter how much the internal auto-registration list
changes that a game can still manage the protocol version
in a graceful way.
Prior to this change, removal of a class registration from
Serializers auto-registered list meant that a client->server
version mismatch was impossible to detect and handle gracefully.
Also, now that it was safe to do so, I removed the auto
registration of some odd Java beans classes.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@9457 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
make it easier to reuse in classes that want to
read/write strings the same way without using
Serializer directly.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@9456 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
some features that will make it slightly less fragile.
The code that registers a serializer for an ID has
been centralized.
A method was added to hand out new IDs and it now
skips IDs that are already in use. This will allow
certain serializers to be fixed against specific IDs
to maintain backwards and forwards compatability even
as the automatically registered list of serializers
changes.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@9455 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
get an exception with the same info (and it's not a
warning anyway, it's fatal).
Also improved the error message to include the field
that failed to write.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@8960 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
close logging to be less verbose... and to not print out
logged infos that look like warnings about "connections
already being closed."
While I was at it, I added so FINE logging about the
sizes of the maps when the elements are removed to make
sure everything is being cleaned up properly.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@8944 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
hindsight about the removal of RenderingHints. :P
Seemed simple enough... but now I have to watch people
get connection errors to my server instead of getting
a nice kick.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@8942 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
server can configure additional ports that will be sent to
the client upon connection. These channels can be used to
send messages in parallel to the normal messages. This is
useful to keeping several separate command pathways flowing
smoothly despite potentially large messages on one channel.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@8938 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
connections.
Early-return in the broadcast method if there are no connections.
This prevents allocation of a message if it's just going to get
dropped on the floor anyway.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@8932 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
- separate jar files for engine components
- resolve dependencies between code parts
- remove Nifty dependency from Cinematics
- remove Physics dependency from TerrainGrid
- add public accessors to Natives Extraction
- remove RenderHint serialization from networking
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@8839 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
when the network connection has been closed. Forcing the selector
to wake up seems to be safe on tested platforms.
Thanks to @philotomy for the catch and fix.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@8669 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
networking layer. Note: because some messages were removed
from Serializer's auto-registration this version is not
binary-compatible with the last. So you must upgrade your
client and server at the same time.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@8286 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
error message than an NPE but still isn't very helpful. This
usually only happens when things are totally confused, ie:
stream corruption or more likely misregistered classes.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@8068 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
plain single thread. This gives more control over the queuing
behavior as with an ThreadPoolExecutor it is difficult to implement
blocking execute() behavior. Also, this avoids creating an
extra object per-message.
Anyway, this code now implements a blocking queue instead of
a boundless queue. It's set to 16,000 messages which should only
bottom out in the worst of cases. I was seeing it in the throughput
tests where the sockets were backing up and the queues were
consuming all of the heap until an out of memory error occurred.
Outbound messaging is only throttled this way on the client.
Servers typically wouldn't do this sort of spamming anyway.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7977 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
protocol. In the wild, I've only seen this crop up in
really really odd circumstances. As it turns out, the
throughput tests eventually trigger this when testing
TCP. I've lost sleep over wondering when this was going
to bite for real so I'm glad to have what is essentially
the last known bug in message transfer fixed.
This change handles the case where so far only one
byte of the two byte message size has been read from
the network. Rare, but it can happen.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7976 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
first the connection added event after sending the
connect confirmation to the client. This prevents
a resource deadlock if the connection listener
tries to send a message to the client and the
client tries to send a response back... since the
client won't have been fully initialized yet.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7854 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
Removed an errant nextId decrement that would occur
even if the class was already registered and already
had an ID. This makes the teetering tower of glass
shards slightly less fragile... slightly.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7722 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
* 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
of the network connection disappearing or any other random errors
on the channel. Now errors that cause the connection to drop
will be properly reported as client disconnects... there is also
a new error field on the DisconnectInfo that is filled in in these
cases.
Added an ErrorListener that can be used to more tightly control
how errors are handled for the Client.
Fixed the double event dispatch that occurred during Client
closing.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7451 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
for the endpoints when using a reliable connection.
There is no guarantee that the buffers going out from
a client won't be chopped up by the networking stack
in various ways. It was always the intent to accumulate
them like this (the client side already does after all)
but it was an oversight. It's a testament to modern
networking that this hasn't come up in practice yet.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7449 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
being serialized automatically.
When a class is final and in the field of a class that
is registered, it is safe to register it automatically
because the type can be determined reliably on the
other end of the stream. So now it allows that.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7276 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
that throw low level exceptions. The specific case I
saw for this was "An existing connection was forcibly
closed by the remote host" IOException. Without this
new handling, SM continually tried to send the connection
its data.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7260 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
the address instead of the socket... since they all share
the same socket anyway and the datagram sockets don't
have useful toString()s.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7256 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
thread. Most of the time UDP packets go right out
but not always... depending on the network layer it can
take a couple of milliseconds. And that's alot when
you're blasting packets out to a dozen users 20 times
a second.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7245 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
