[17116] in Kerberos_V5_Development
Re: [RFC][PATCH] krb5 => libverto main loop
daemon@ATHENA.MIT.EDU (Roland C. Dowdeswell)
Wed Aug 24 11:41:11 2011
Date: Wed, 24 Aug 2011 16:41:08 +0100
From: "Roland C. Dowdeswell" <elric@imrryr.org>
To: Nathaniel McCallum <npmccallum@redhat.com>
Message-ID: <20110824154108.GU25532@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1314199881.2181.4.camel@localhost>
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, Aug 24, 2011 at 11:31:19AM -0400, Nathaniel McCallum wrote:
>
> 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.
Yes. Also, the 1024 limit is not on TCP connexions but rather on
the maximum fd that is processed by the event framework (well,
select(2)). If you are going to be running code written by third
party developers in the form of plugins, you have no idea how many
fds they might decide to use. It becomes much more likely that
one would run into select(2) issues if one imagines poorly written
plugins...
--
Roland Dowdeswell http://Imrryr.ORG/~elric/
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
