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
internal bits. Only report that a session ended if we reported that it started,
but always clear out our bits when a session is shutting down.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5659 542714f4-19e9-0310-aa3c-eee0fc999fb1
we're proxying for a client, we now have to give up our ClientObject to anyone
who wants it, so that they can do access control checks.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5593 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
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
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