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
to make sure that the connection closed change event
only goes out once.
Added some additional logging to the endpoint closings.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7244 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
in real life.
Fixed a subtle bug with the UDP endpoints where they weren't
getting propery closed. This manifested as the endpoints
still getting broadcasts even after Server no longer knew
about them.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7243 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
being written hasn't been registered yet and does not
have an explicit ID set. The old way would try to send
it anyway and then it would fail to get received on the
other end.
A setStrictRegistration(false) method can be used to get the
old behavior if needed.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7222 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
the rest. Added an UnsupportedOperationException to
SerializableSerializer so that it doesn't silently fail
to do anything at all.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7219 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
to read from a buffer and doesn't understand what class
it's reading. Error messages... it's the little things
that matter.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7180 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
issue left over from when the long -> int client ID
conversion was made. Now connection lookups work again.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7152 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
if there are events to deal with. This wasn't a big
deal for connects because there's always an accompanying
message but for disconnects we wouldn't get events until
the next message came through. Always meant to go back
and fix it and now I have. Note: this is because our
adapters use a single thread for pulling envelopes off
and for dispatching connection events.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7123 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
single-arg registerClass() method now throws an exception
if the object is not marked Serializable. Internally,
the package-load stuff uses the new alternate method that
allows safe non-exception throwing registration since it's
hitting it with every class in a package.
Interestingly enough, messages will still get written out
because of some questionable code in writeClassAndObject()...
but it won't be read as anything but null despite its
40+ bytes of data.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7121 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
the case of nulls. Note: this is specific to
serialized objects and is therefore not adding
a byte to things like Strings or arrays... those
will have to be reviewed separately.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7119 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
Client and server should match or bad things happen and it
might be worth adding this to the connection negotation
as a validation.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7106 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
last minute shifts in APIs. Anyway, outbound TCP
broadcasts work again and are more efficient since the
Kernel callers can better control when their message
buffers are copied (in this case it isn't necessary so
we save a buffer copy).
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7088 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
way made the caller specify a local port due to an unusually
persistent bit of ancient lore lodged in my brain.
git-svn-id: https://jmonkeyengine.googlecode.com/svn/trunk@7086 75d07b2b-3a1a-0410-a2c5-0572b91ccdca
PSp..om
sha..rd
nor..67