that would throw a NotYetConnectedException when you tried to write to it. Yes,
you'd definitely think that.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5865 542714f4-19e9-0310-aa3c-eee0fc999fb1
the case for an outgoing connection since we do our connection asynchronously)
and a connection that is no longer connected because it once was open and now
it's closed.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5855 542714f4-19e9-0310-aa3c-eee0fc999fb1
operations, but previously if someone called destroy on an uninitialized DObject or called
PresentsDObjectManager.destroyObject with its oid, it'd be destroyed. Subscribing to objects
depends on that object existing, so if it's destroyed, the server will continue to function normally
except that subscription requests will be silently dropped.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5851 542714f4-19e9-0310-aa3c-eee0fc999fb1
dependency, but we can inject RunQueue which will Guice will magically defer to
avoid the circularity.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5847 542714f4-19e9-0310-aa3c-eee0fc999fb1
specialized ReportManager, let's just not activate them by default.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5846 542714f4-19e9-0310-aa3c-eee0fc999fb1
PresentsSession, we don't need to or want to change our auth name, we can and
should operate entirely on ClientObject.username. The ClientManager maintains
two mappings: "current username" -> ClientObject (which is what needs to change
when setUsername or updateUsername is called) and "authname" -> PresentsSession
which has always been just the authname and has never changed during the course
of a session. PresentsSession.getUsername() goes away and
PresentsSession.getAuthName() always returns the name that was used to
authenticate the session.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5838 542714f4-19e9-0310-aa3c-eee0fc999fb1
authenticators and chained session factories. We can share a lot more code this
way and the implicit requirement that the default authenticator/factory had to
be configured before anyone else configured a chanied author/factory is gone.
The other big change is that Credentials doesn't require a username
(UsernamePasswordCreds inherits that username so most derived classes don't
notice any difference). Instead we require that a canonical authentication
username be determined and configured in AuthingConnection during the
authentication process. This canonical username is then used to resolve the
client session and map everything in the client manager.
This is pretty much exactly what was going on before except that we were doing
it all in an ad hoc way by jamming a new name into Credentials during the
authentication process and also doing jiggery pokery in
PresentsSession.assignStartingUsername. That all goes away and/or becomes
cleaner and more explicit.
This is going to impact some Yohoho jiggery pokery, which I will shortly commit
a patch for, but we're going to need to test it. Omelets, eggs, etc.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5828 542714f4-19e9-0310-aa3c-eee0fc999fb1
messages, treat that like a network failure which will clear out that queue and
shutdown the connection. Overflow queues are only meant to handle sockets that
are backed up, not closed or non-existent.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5813 542714f4-19e9-0310-aa3c-eee0fc999fb1
non-work project). I promise to stop fooling around now.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5805 542714f4-19e9-0310-aa3c-eee0fc999fb1
server business. I'd move the whole kit and kaboodle to samskivert but that
would mean moving the DependencyGraph as well...
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5804 542714f4-19e9-0310-aa3c-eee0fc999fb1
initialization and shutdown. This will obviate the need for a lot of manual
wiring up. ShutdownManager still works and passes through to LifecycleManager,
but switching to the new deal is encouraged.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5802 542714f4-19e9-0310-aa3c-eee0fc999fb1
hostname, in hopes of fixing the issue with receiving datagrams
from the staging server.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5793 542714f4-19e9-0310-aa3c-eee0fc999fb1
the server starts sending datagrams willy-nilly, it must wait for
a (reliable) go-ahead from the client. Otherwise, it's possible
that the server may be successfully receiving datagrams but not
sending them.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5792 542714f4-19e9-0310-aa3c-eee0fc999fb1
point Pulse can probably totally replace the ReportManager at which time a
bunch of cruft can go away.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5757 542714f4-19e9-0310-aa3c-eee0fc999fb1
logging in a fine-grained way in a running server.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5744 542714f4-19e9-0310-aa3c-eee0fc999fb1
sending it on the stream. However, also increase the maximum
datagram size.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5670 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne