outstanding know that their subscription request failed.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4873 542714f4-19e9-0310-aa3c-eee0fc999fb1
(which runs on the server) that we do in a normal client (which runs on a
user's computer). Eventually we'll make a custom Communicator for use on the
server that integrates with the ConnectionManager's polled socket I/O which
will be easier now that this bit of factoring has been done.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4835 542714f4-19e9-0310-aa3c-eee0fc999fb1
separate thread and racing against other client actions. Also nixed a pointless
type check and cast.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4828 542714f4-19e9-0310-aa3c-eee0fc999fb1
everything in two languages. Especially when one doesn't support inner classes
and has non-C syntax just to make life easier for parser writers.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4762 542714f4-19e9-0310-aa3c-eee0fc999fb1
and the ProxySubscriber mechanism by which the server proxies for the client.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4730 542714f4-19e9-0310-aa3c-eee0fc999fb1
another server. The PeerManager needs both to rewrite the oid of the events
before dispatching them and to assign an eventId to them so that they will not
be filtered by PresentsClient when deciding whether or not to send them along
to its client. Also fixed compound event dispatch in the process. Now proxy
subscribers will be notified once of a compound event rather than of each
individual internal event.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4729 542714f4-19e9-0310-aa3c-eee0fc999fb1
to fail if a director tries to register services groups but was not created
until after the client was logged on.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4557 542714f4-19e9-0310-aa3c-eee0fc999fb1
notion of a global group (though we implicitly define one in InvocationCodes)
added a mechanism for directors (which generally handle the client side of
invocation services) to register their interest in bootstrap service groups so
that the whole goddamned complex business can happen magically behind the
scenes.
If you instantiate a director, it will automatically register interest in the
service group it needs and everything will work. If you don't use the director
code, you don't get the services and you can safely exclude all of that code
from your client even though the services are still in use on the server (and
presumably used by some other types of clients).
This is going to break all the builds, which I'll soon fix. Then I'll go write
all this in ActionScript. Yay!
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4552 542714f4-19e9-0310-aa3c-eee0fc999fb1
MetaSOY clients (Swiftly, World, and soon Admin Dashboard) don't have to know
about a bunch of unrelated crap. Fricking complexity++, grumble.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4551 542714f4-19e9-0310-aa3c-eee0fc999fb1
inner bits are all clear and ready to try logging on to a new server. We
specifically wait to call clientLogonFailed() until after everything is
cleared, but I don't want to change the behavior of clientDidLogoff() for fear
that any one of the zillion directors depends on something being around during
that call.
Instead I added another callback clientDidClear() that is called when a
successful session is fulled cleared out (basically when we're not calling
clientLogonFailed()) so that entities that are waiting for a logoff to finish
so that they can logon somewhere else have a clean way of doing so.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4255 542714f4-19e9-0310-aa3c-eee0fc999fb1
make connections to other servers in the cluster and can exchange events (in a
limited fashion).
This is different than Liz's project wherein servers share an oid space and one
can interchangably work with distributed objects from any server. This package
provides a means by which certain services (by default, presence and chat) can
be communicated between servers to allow communication between players
scattered around a bunch of otherwise independent server instances.
This is less general purpose but also less likely to encourage people to write
code that tightly couples multiple servers and then falls over because it
generates gobs of network traffic as events are flung willy nilly behind the
scenes.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@4238 542714f4-19e9-0310-aa3c-eee0fc999fb1
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
- if a pong response took more than 5 seconds to receive, another ping
would be sent. When the pong finally arrived the delta would be
calculated using the most recently sent ping.
Fix: don't send more pings while waiting on a pong.
- After a pong is received, the _deltas array is mangled while
calculating the server delta, making subsequent pongs possibly
overwrite earlier calculated deltas.
Fix: calculate using a copy.
Also, changed the delta calculation to be the mean of the deltas rather
than the median. Left code in to do it both ways if this change was not
kosher...
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3990 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
(in fixed framerate format) with the Presents event queue in what will
hopefully be happy harmony. Also made some edits to the Presents code to
not sound like we assume things run on the AWT thread which we don't and
which is not the case in this framework.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3510 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
the throes of a previous connection. Also don't spuriously recreate our
ticker because it's very possible for logon() to be called and not
logoff(), logon() might fail, for example.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3321 542714f4-19e9-0310-aa3c-eee0fc999fb1
There is no more SafeInterval, instead Intervals can be constructed with a RunQueue to use for expiring.
PresentsDObjectMgr implements RunQueue.
Client has a getRunQueue() method to get the client side RunQueue.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@3283 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
the math appears to work out even though time stopped. We can use
RunAnywhere.currentTimeMillis() which will warn if time goes backwards but
since when that happens the IntervalManager stops dead in it's tracks,
we'll never get ticked to find out about it. Fucking Windows.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2911 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
observed after the last subscriber of a matching distributed object has
been removed. Our client's subscription will not be flushed until after
the delay has expired, and only then if no other subscriber has come along
requesting the object in the meanwhile.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@2303 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne