Re: couple socket-connection questions

[Ken Raeburn <raeburn@MIT.EDU>]

Buck Huppmann wrote:
>>just wondering if there are plans to implement a connection timeout
>>mechanism in send_to_kdc(), since, for TCP connections, the OS time-
>>out on the connect() call is long enough to cause severe latency if,
>>for whatever reason, UDP connections won't work (e.g., stateless
>>UDP port filtering) and the preferred KDC is down. this is particu-
>>larly painfell, e.g., if you're using pam_krb5 or the like under
>>such circumstances

With non-blocking connect() calls, any timeout (well, any shorter than
the OS TCP timeout) can be implemented in the library code fairly
easily.  MIT's upcoming release does this.  (The timeout is an
artifact of how many servers and UDP vs TCP, but using a fixed number
or config file entry would be easy.)  It seems to work pretty well.
Shouldn't be hard to do it for Heimdal too.

Luke Howard <lukeh@PADL.COM> writes:
> Making the KDC fork() or multi-threaded for TCP clients would also be
> useful. Thoughts?

Connections probably won't be long-lived in most cases.  Forking is
probably much more overhead than is warranted, unless you've got too
many incoming connections for one process to keep them all open for
short periods of time.  (If they stay open without giving you data,
you probably just want to shut them down.)  Multiple threads may be
useful for a multiprocessor or hyperthreaded server, but I doubt one
thread per connection is the way to do it; you probably wind up with
lots of short-lived threads, and it gets more difficult to do things
that want to know about multiple connections (say, denial of service
defenses against a single source address making lots of connections
and holding them open -- you may want to just shut them all down).

Managing a buffer per connection out of a single thread isn't that
tough.  Nor is using non-blocking sockets.  Is KDC performance on
multiprocessor systems really a problem for anyone (except Microsoft)
right now?

FWIW, the MIT KDC is still single-threaded.  We've got TCP support,
though it's turned off by default at the moment because I want better
protection against denial of service attacks than we have right now.

Ken