> I am writing an imap proxy. I want to limit the number of client
> connections. When the maximum limit is reached, I want to kill existing
> idle connections when a request for a new connection arrives.
This is a very bad design.
First, it provides a trivial denial-of-service attack. I can blow
off all your existing connections simply by opening a bunch of
dummy connections to the proxy server.
Secondly, it can cause a client to needlessly thrash connections
to the server. Many clients hold more than one connection open.
Imagine a client that uses two connections (one control channel,
and one to operate on the current folder). The client opens the
control channel. This succeeds, however the proxy is now at its
connection limit. When the client opens a folder, it could bump
the control connection. This will cause the client to almost
immediately re-open the control connection, possibly causing the
folder connection to close. Etc. (Most likely it's going to cause
other clients to get kicked, but that isn't any better.)
The correct behaviour is to simply refuse new connections when the
proxy hits its limit.
> Is closing the connection a good idea? I mean will the client get an
> error?
See above.
> Would sending a BYE command before I close the connection be a
> better idea?
Servers should always send an untagged BYE before closing a connection
asynchronously.
> Another question. Do clients like (Outlook, Netscape, Eudora, etc)
> reopen client connections if they find that the server has closed the
> connection.
If the connection idles out they will open a new connection when
they need it. If the connection is closed while there are outstanding
operations, they usually don't (treating that as an error condition).
--lyndon
[This firm] is the only company that's shipping end-user networking
software that conforms to OSI standards. The OSI stamp is important
because it assures corporate users that the networking software will
easily connect to other vendors systems and software.
-- pyramid!csg via r.h.f.
