Re: NOOP command - your feedback needed

[David Madeo <David.Madeo@xxxxxxxx>]

Steve Mansour wrote:

> We've seen a problem in the way the NOOP command is used (or misused)
> in IMAP. Clients issue NOOP commands to keep the connection to the
> server alive. This can cause a situation where lots of clients log in
> to a server, hold their connections open for hours during which they
> sit idle (except for issuing the NOOP commands). Others trying to
> access the server during this time will receive connection refusals or
> "server too busy" errors.

In corporate type situations where bandwidth isn't an issue and keeping
the connection open is better than the small delay for tearup/down, I'd
configure the server to leave the connection up as long as NOOP's keep
arriving.

In a different situation where the bandwidth is an issue and the small
delay of establishing a connection is better than keeping the
connections open, I'd configure the server to drop the connection after
the 5th consecutive NOOP.

In any case, the client should be responsible for reconnecting to the
server whenever required.  If the "newevents?" timer expires, the client
should ask the server if anything new has arrived.  If the user starts
doing something in the client, it should check the connection and
reestablish with no further action on the part of the user.

Ideally as a user, I won't even know that it was doing so.  

> It is also used as a way to get the IMAP server to spew back pending
> data. That is, the NOOP command is being used in a way it probably
> wasn't intended to be.

This sounds wrong.  It's not a "get new messages", it's the equivalent
of ping.

> So, the questions are:
> 
>    * Do we really want a NOOP command in CAP?

Yes.  

>    * If so, it seems like we might want to allow the server to drop
>      the connection anyway to avoid idle connections building up.  So,
>      the server should probably be able to drop a connection at its
>      discretion.  Do we _really_ want a NOOP command?

The server should be able to ignore the NOOP and drop the connection
whenever required.  The client should attempt to reconnect with a
backoff algorithim to prevent loading.

dmadeo