A small drawback to Wietse Venema's TCP Wrappers

July 6, 2008

Wietse Venema's tcpwrappers is mostly used for controlling access to services run from inetd or your local equivalent, where you are not expecting high performance or high load. However, it can be built as a library that you link your daemon against, and some daemons are.

(At least on Linux, both OpenSSH and the portmapper are built this way.)

It turns out that there is a small drawback to using tcpwrappers this way in some sorts of high-performance applications, specifically in application where you expect a lot of connections or want to be able to dispatch connections very fast. The drawback is this:

Tcpwrappers does no caching of the hosts.allow and hosts.deny files.

Every time you call the tcpwrappers routines to check for host access, they open, read, and parse the files completely from scratch. If your files are small, this doesn't matter, but if they're large, you may be burning more CPU time on this than you expect.

(You're very unlikely to be hit with disk IO for reading the files; if you're getting any sort of connection volume they'll be in the filesystem cache.)

One useful thing to know for best performance is that tcpwrappers deals with the files strictly a line at a time (instead of parsing the entire file, then evaluating the parsed rules). This implies that it's worth putting the rules for the most common cases first if you have big files.

(Big hosts.allow and hosts.deny are probably uncommon, but I once had a hosts.deny file that was over 4,000 lines long. That was admittedly a special case, and eventually got replaced with better technology.)

Written on 06 July 2008.
« How OOXML is a complete failure, even for Microsoft
A (D)VCS feature that I'd really like »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Jul 6 01:17:12 2008
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.