|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
From: Nathaniel McCallum <npmccallum@redhat.com> To: "Roland C. Dowdeswell" <elric@imrryr.org> Date: Wed, 24 Aug 2011 11:31:19 -0400 In-Reply-To: <20110824152652.GT25532@mournblade.imrryr.org> Message-ID: <1314199881.2181.4.camel@localhost> Mime-Version: 1.0 Cc: Ken Raeburn <raeburn@mit.edu>, Sam Hartman <hartmans@mit.edu>, Tom Yu <tlyu@mit.edu>, "krbdev@mit.edu" <krbdev@mit.edu> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: krbdev-bounces@mit.edu On Wed, 2011-08-24 at 16:26 +0100, Roland C. Dowdeswell wrote: > On Wed, Aug 24, 2011 at 09:24:18AM -0400, Nathaniel McCallum wrote: > > > > > > Yes, a KDC could have more than 1024 TCP connections. > > > Rare but possible. > > > > The risk for this increases once we began handling multiple requests > > simultaneously. Before this, accept() would never execute until the > > previous request had called close(). Async programming almost always > > increases the number of fds used dramatically. > > The current KDC can process simultaneous TCP connexions. It already > async. Yeah, Sam already pointed that out to me. What is currently async is reading and writing to the socket. What is not yet async is the actual processing once the reading has been done in order to generate a response. With OTP getting added as a pre-auth mechanism, this time spikes dramatically. Currently this is synchronous and will block accept(). The libverto patch so far should do nothing to increase the number of FDs. However, once we insert OTP pre-auth into that chain, FDs will remain open for much longer than previously. So in short, what will increase the numbers of FDs in play will be the introduction of OTP pre-auth methods. Nathaniel _______________________________________________ krbdev mailing list krbdev@mit.edu https://mailman.mit.edu/mailman/listinfo/krbdev
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |