You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Many kinds of servers want to limit the maximum number of concurrent connections they'll accept in order to bound their resource commitment. It's a bit non-obvious how to do this in NIO, but it's not terribly difficult to do. Things that are non-obvious but straightforward are a fairly good candidate for implementation in this module.
In this case, the mechanism for achieving this is to provide a ChannelDuplexHandler that users would insert .first in the server channel pipeline (using serverChannelInitializer). This handler would delay the read call in cases where the maximum number of connections has been reached. It can keep track of new connections using inboundIn and it can record when connections close by using the Channel.closeFuture.
A really great implementation would be able to tolerate both a "flexible" maximum and a hard cap. In hard-cap mode we'd need to set maxMessagesPerRead to 1 in order to prevent over-reading (though the handler could dynamically twiddle this setting). In "flexible" mode we'd allow a slight overrun, up to maxMessagesPerRead - 1 extra connections.
The text was updated successfully, but these errors were encountered:
I'm pretty sure I did a very crude version of this in my first weeks at Apple, I might even have a very basic implementation lying around on a branch somewhere.
Many kinds of servers want to limit the maximum number of concurrent connections they'll accept in order to bound their resource commitment. It's a bit non-obvious how to do this in NIO, but it's not terribly difficult to do. Things that are non-obvious but straightforward are a fairly good candidate for implementation in this module.
In this case, the mechanism for achieving this is to provide a
ChannelDuplexHandler
that users would insert.first
in the server channel pipeline (usingserverChannelInitializer
). This handler would delay theread
call in cases where the maximum number of connections has been reached. It can keep track of new connections usinginboundIn
and it can record when connections close by using theChannel.closeFuture
.A really great implementation would be able to tolerate both a "flexible" maximum and a hard cap. In hard-cap mode we'd need to set
maxMessagesPerRead
to1
in order to prevent over-reading (though the handler could dynamically twiddle this setting). In "flexible" mode we'd allow a slight overrun, up tomaxMessagesPerRead - 1
extra connections.The text was updated successfully, but these errors were encountered: