need to first construct an instance with nulls. Also added newTuple(). Opted
not to make newStreamableTuple() as that would make more sense in a Tuples
class, but this method can only be accessed by calling StreamableTuple.newTuple
which seems to me to already tell the whole story.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5556 542714f4-19e9-0310-aa3c-eee0fc999fb1
* Use _writer != null iff the socket is open and the authrequest has been sent
* Warn when posting messages prior to socket connect
* Clear the outgoing queue prior to sending the auth request, the servers authing connection expects this
* If a logoff is encountered prior to the socket opening, just shut down without sending auth request
* Driveby unused variable removal
This should fix the log warning "AuthingConnection$1: Received non-authreq message during authentication process"
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5548 542714f4-19e9-0310-aa3c-eee0fc999fb1
peer disconnects for any reason, end its session immediately.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5546 542714f4-19e9-0310-aa3c-eee0fc999fb1
something friendly and drop the request. The server is about to go away.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5545 542714f4-19e9-0310-aa3c-eee0fc999fb1
utility in sending pings before we're authenticated.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5543 542714f4-19e9-0310-aa3c-eee0fc999fb1
ClientManager and it is already pretty tightly coupled to the ConnectionManager
so we weren't really fooling anyone with that ham-fisted attempt at
abstraction.
Also cleaned up more mid-shutdown behavior. If a session is unmapped after the
omgr exits, avoid generating a warning by trying to hop onto the omgr thread to
clean up after ourselves. We still do all the actual socket related closing so
that the party on the other end of the socket benefits from a clean shutdown
where possible.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5537 542714f4-19e9-0310-aa3c-eee0fc999fb1
we fail to bind to any of our desired ports. We'll just do that automatically
because no one wants a totally hapless server sitting around unable to actually
accept any connections.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5536 542714f4-19e9-0310-aa3c-eee0fc999fb1
dealing with normal operation.
Nixed getFlattener() in favor of createDatagramSequencer() so that the
ConnectionManager doesn't have to expose its guts quite so much.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5535 542714f4-19e9-0310-aa3c-eee0fc999fb1
seconds so that we can see more about what's going on if we manage to recreate
our freakoutery.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5532 542714f4-19e9-0310-aa3c-eee0fc999fb1
PresentsDObjectMgr to achieve a coordinated shutdown.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5531 542714f4-19e9-0310-aa3c-eee0fc999fb1
ahead and actually register ourselves with the ShutdownManager.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5530 542714f4-19e9-0310-aa3c-eee0fc999fb1
initiated by the client, but we always want to stop our ticking.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5519 542714f4-19e9-0310-aa3c-eee0fc999fb1
think it should be needed but I need to do more testing, post-bling.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5517 542714f4-19e9-0310-aa3c-eee0fc999fb1
Don't wait up to 60 seconds for the next peer refresh interval.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5514 542714f4-19e9-0310-aa3c-eee0fc999fb1
polled socket system. This much more cleanly and efficiently integrates peer
(and other server to server) connections into the normal server I/O framework
and should also eliminate for good the annoying server hangs that result when
our old blocking client I/O threads got their pants wedged.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5510 542714f4-19e9-0310-aa3c-eee0fc999fb1
Michael Bayne