[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: misc/18947 (ftpd lacks a per host limit of simultaneous connections)
The following reply was made to PR misc/18947; it has been noted by GNATS.
From: Matthew Mondor <mm_lists%pulsar-zone.net@localhost>
Subject: Re: misc/18947 (ftpd lacks a per host limit of simultaneous
Date: Sun, 14 Mar 2010 17:24:59 -0400
Since I implemented such a limit system on a few daemons in the past, I
took a brief look at the ftpd code.
In the code I previously adapted to support such limits, only daemon
mode was supported and as such it was easy to use a global shared hash
table in a MAP_ANON region along with flock(2). Other cases were
multithreaded so it was even easier.
Allowing inetd introduces performance penalties and complexity for this
scenario, I think. From what I see, the current per-class connections
limits is calculated via count_users() which actually uses a file of
Following a similar route, I guess that it'd be possible (and
simplest), to implement per-address limits using a file as well, using
dbopen(3)/hash(3) to store per-address information such as a
connection/refcount. Alternatively, instead of only storing the pid_t
in the pids file, it'd be possible to store pid_t+address but running
through the set testing for every match would be suboptimal.
Other alternatives would be using a second mmap(2)d shared file
implementing a hash table, or sysvipc, but I doubt that this would
really be better than bdb for real use, and it would be more complex to
implement, some code actually duplicating what bdb might be doing.
Apart from chosing the way this hash table should be stored and
accessed, since ftpd supports several address families, I think that
some address-family specific code will have to be used, because the
address size is different for each family, and this is what we should
be hashing. It'd also be possible to serialize the address to string
before hashing using inet_ntop(3) or equivalent, costing a few more
In a better world, it'd probably be possible to adapt all local daemons
to support such policies by sharing a lightweight database daemon
replacing or supplementing utmp and allowing sophisticated and
efficient user WHO queries, internally using a library with a decent C
API to also do queries from C... :) But we don't currenty have this.
Main Index |
Thread Index |