open when a ConnectionManager using them shuts down.
BindingConnectionManager takes on the duties of opening sockets that ConnectionManager used to
handle, and it's injected automatically by PresentsServer. Hopefully that means this won't change
anything for existing users of PresentsServer.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6157 542714f4-19e9-0310-aa3c-eee0fc999fb1
the last opened. Close all opened listening sockets.
Also, the last opened datagram socket would be used to send all datagram messages instead of the one
datagrams were received on. It now goes through the same channel where datagrams were last
received.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6156 542714f4-19e9-0310-aa3c-eee0fc999fb1
wildcard address for TCP in order to accept connections on both the
public hostname and the internal hostname used for peers, but bind to the
public hostname for UDP because binding to the wildcard address seems to
cause problems receiving packets).
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@6066 542714f4-19e9-0310-aa3c-eee0fc999fb1
actually reduce latency, but wouldn't it be cool if it did?
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5985 542714f4-19e9-0310-aa3c-eee0fc999fb1
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
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
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
while we're processing its overflow messages, which causes its overflow queue
to be cleared which causes a ConcurrentModificationException.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5613 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
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
accept new connections or read incoming messages from any of our extant
connections. Do send outgoing messages to those connections, but nothing else.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5493 542714f4-19e9-0310-aa3c-eee0fc999fb1
* Throw an exception if any events, runnables or messages are posted after shutdown. These were previosuly being silently ignored. We really should know about them.
* Don't exit the connection manager thread until the object manager thread exits. This fixes a race condition where the wakeup time of the conmgr thread would determine if it shutdown before or after the object manager, meaning it would sometimes ignore messages around shutdown time.
* Add a shutdown constraint to make the client manager shutdown before the invoker/event/conmgr threads. This gives a single point in the shutdown sequence that applications can use as a constraint (TODO: shutdown groups?)
* Emit a log message for each shutdown method call. This could be very useful in production.
git-svn-id: svn+ssh://src.earth.threerings.net/narya/trunk@5491 542714f4-19e9-0310-aa3c-eee0fc999fb1
Dave Hoover