on multiple ports, falling back from one to the next as appropriate.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4158 542714f4-19e9-0310-aa3c-eee0fc999fb1
genericize Narya data structures, nor make the existing code type safe. That's
going to be an extremely large project.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4007 542714f4-19e9-0310-aa3c-eee0fc999fb1
completely cleaned up so that an immediate attempt to logon using a
different configuration will not fail due to the client thinking it's
still logged on from the previous failed attempt.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3658 542714f4-19e9-0310-aa3c-eee0fc999fb1
that authentication is processed on the dobjmgr thread rather than
requiring the caller to do the right thing (or not as the case happened to
be).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3433 542714f4-19e9-0310-aa3c-eee0fc999fb1
condition between the omgr thread and the conmgr thread. Now when the omgr
thread processes an event that is going out to the clients, it flattents
the message itself for each client that is to receive the message and the
flattened data is posted to the conmgr outgoing queue.
This means that once an event is finished processing, no further
modifications to any of the data associated with the event can effect the
data queued up to be sent to the client. This is a good thing, it will
eliminate or illuminate a very baffling class of bugs that we've sort of
been ignoring because we knew this could be the cause.
We used to take an event and flatten it directly into the direct buffer
from which we would do our socket write. Now we flatten it into a
temporary byte array. This means a metric shitload more garbage generation
and collection. We used to do the flattening on the conmgr thread, now we
do it on the omgr thread. This means a big redistribution of CPU demand.
Either of those things could result in a significant negative impact on
our performance, but we'll just have to deploy this stuff and find out.
Whee! If it turns out to be a serious problem, there are potential
optimizations that could be done by keeping a pool of direct buffers
around and flattening messages into them, relying on the fact that the
outgoing conmgr queue generally doesn't grow too large and we could
allocate tens to a hundred megabytes of memory for the outgoing queue if
we really needed to.
I'd also like to test the overflow handling stuff more. It didn't really
change in that everything just deals with arrays of bytes now instead of
unflattened messages, but I'll be more comfortable once I've seen all this
in action on ice where there may be few users, but they are just as likely
to experience lag and receive an overflow queue as users on the higher
traffic servers. There is code to log when overflow queues are created and
finally flushed and how much use they got while they were around, so that
should give us an indication of whether things are operating properly.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3419 542714f4-19e9-0310-aa3c-eee0fc999fb1
the first 80 characters if this every actually discovers an anomaly rather
than just dutifully reporting every time someone updates really lengthy
crew news.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3409 542714f4-19e9-0310-aa3c-eee0fc999fb1
together in one JVM and both interoperate with the AWT thread in a manner
so harmonious as to bring a tear to the eye. This was surprisingly much
easier that I expected, thanks to my eminently sensible initial design,
I'm sure. ;)
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3360 542714f4-19e9-0310-aa3c-eee0fc999fb1
classloader to use when unserializing objects off the network. Also fixed
the way custom classloaders were used as Class.forName(class, true,
loader) seems to be the proper way to go to have caching work and whatnot.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3268 542714f4-19e9-0310-aa3c-eee0fc999fb1
Windows where it wigs out and behaves as if the connection was reset by
the peer ("An existing connection was forcibly closed by the remote host")
if one writes messages bigger than about 25k. I can't imagine how we would
be sending such big messages to the server, but it's worth a check.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3159 542714f4-19e9-0310-aa3c-eee0fc999fb1
seconds to pass in between ping/pong latency samples. Additionally, we
resync the clock every 10 minutes.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2748 542714f4-19e9-0310-aa3c-eee0fc999fb1
the server in 90 seconds. The client is set up to ping the server if it
has had nothing to say to it for other reasons in the last 60 seconds.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1860 542714f4-19e9-0310-aa3c-eee0fc999fb1
after both the reader and writer have exited (otherwise the reader could
exit before the writer which would result in the client chucking its
reference to the communicator which could subsequently bite us in the ass
if anyone tried to reference the client's distributed object manager when
the writer finally exited and triggered all of the clientDidLogoff
callbacks). Multithreaded programming is fun!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@1396 542714f4-19e9-0310-aa3c-eee0fc999fb1
changed to Presents and Party changed to Crowd. Whee!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@431 542714f4-19e9-0310-aa3c-eee0fc999fb1
packages. These contain all the message codes as well as error response
codes that are used by a particular invocation service.
Also changed client.LocationManager to client.LocationDirector and
chat.ChatManager to chat.ChatDirector to go along with the new philosophy
of naming the client-side managing entity for an invocation service a
director.
Also elimitated cocktail.util.Codes since it's no longer used as a central
repository for codes (instead they are in InvocationCodes and its
derivatives).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@368 542714f4-19e9-0310-aa3c-eee0fc999fb1
test server to make some testing easier; various other cleanups.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@188 542714f4-19e9-0310-aa3c-eee0fc999fb1
can get shit together before bootstrapping the client.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@68 542714f4-19e9-0310-aa3c-eee0fc999fb1
the facilities for fetching (without subscribing to) an object. This is
done extremely rarely and the user might as well just subscribe and
immediately unsubscribe because the dichotomy between fetching and
subscribing just served to overly complicate the internals for no good
reason.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@30 542714f4-19e9-0310-aa3c-eee0fc999fb1
Mike Thomas