mailing list archives

I am using a Cyrus Server and what is occuring is that
LOGOUT command can take some time.

As I am writing a user interface, when the user will quit the  
application, all connections will be stopped. For IMAP connections, I  
was sending LOGOUT command. And it is unacceptable for a user to wait  
much time when quitting especially when it is doing nothing more than  
notifying the server that we are going to disconnect from it. As I  
maintain one connection for each folder, when we have several folders,  
it takes age (in some case, I have to wait 30 seconds).
I tested a TCP disconnection without sending LOGOUT command and it is  
much more faster (less than one second).
Is something will be breaking if we don't send the LOGOUT command ?

Is there a recommended behavior to adopt to avoid that problem ?

-- 
DINH V. Hoa,

"un joint tu vas pas avoir ton cerveau d?truit ? la longue" -- b

On Fri, 30 Jun 2006, DINH Vi?t Ho? wrote:
> Is something will be breaking if we don't send the LOGOUT command ?

It's not a good idea.

(1) Some servers may perform a cleanup or checkpoint operation during 
LOGOUT.  Of course, the server will try to trap disconnect, and do the 
checkpoint anyway in the trap handler.  However, a few (thankfully, rare) 
OS environments send mandatory (non-trappable) kills to servers on 
disconnect.  Thus, the disconnect can actually cause a loss of cleanups or 
mailbox updates!

This is a real problem in some mailbox formats (e.g., traditional UNIX 
mailbox format).  It is very expensive to update the mailbox file, so flag 
changes are deferred until a checkpoint.

(2) The server is going to log the disconnect as a non-LOGOUT session 
termination event.  It has no way of knowing that the client intended to 
do this.  This, in turn, leads to false bug reports.

> Is there a recommended behavior to adopt to avoid that problem ?

Yes.  There is no reason why your client must block waiting for the server 
to LOGOUT.  All it has to do is send the LOGOUT command and defer closing 
the TCP connection until the BYE and OK response comes back.  In the 
meantime, it can do something else.

In a multithreaded environment, the LOGOUT could be given to a thread. 
Alternatively, the client can fork off another instance of itself 
(invisible to the user), let the fork have the sockets and go off on its 
own, and the parent fork which has the user interface forgets the sockets.

This way, the user sees an immediate termination, whereas behind the 
curtain the funny man is busy pulling the levers and twirling the dials.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

My suggestion:

Send LOGOUT at the same time on all your connections, wait for one 
second (you need not listen for responses), and quit.

The connection close packets will arrive at the server about 0.8-1.2 
seconds after the LOGOUT commands, so the servers have started 
processing LOGOUT by that time, and most servers will only discover 
that the connection was closed when they've finished doing the logout 
processing. (There are exceptions. At least one server discovers it 
sooner.)

This won't hurt the servers. You're behaving much like a random laptop, 
so any server which has a problem with your behaviour has a problem 
with normal laptop clients, too. (When a user closes the lid, the 
laptop has to sleep right there and then. Not 30 seconds later.)

Arnt

Mark Crispin writes:
> (1) Some servers may perform a cleanup or checkpoint operation during 
> LOGOUT.  Of course, the server will try to trap disconnect, and do 
> the checkpoint anyway in the trap handler.  However, a few 
> (thankfully, rare) OS environments send mandatory (non-trappable) 
> kills to servers on disconnect.  Thus, the disconnect can actually 
> cause a loss of cleanups or mailbox updates!

Don't you think the servers on such platforms should deal with it, 
instead of expecting all clients on all platforms to do so?

For example, a server on such a platform can fork off another intance of 
itself (invisible to the client), close the IMAP connection, and let 
the client go on its way? Instead of expecting the client to -

> fork off another instance of itself (invisible to the user), let the 
> fork have the sockets and go off on its own, and the parent fork 
> which has the user interface forgets the sockets.

Your next paragraph describes both:

> This way, the user sees an immediate termination, whereas behind the 
> curtain the funny man is busy pulling the levers and twirling the 
> dials.

Arnt

On Fri, 30 Jun 2006, Arnt Gulbrandsen wrote:
> (When a user closes the lid, the laptop has to sleep 
> right there and then. Not 30 seconds later.)

Not so!  I've seen sleep-on-lid close take quite a bit longer than 30 
seconds on some laptops; each running running application must respond to 
a system sleep event.  To further muddy the waters, a running application 
has the right to cancel the sleep!

The only true "SHUT DOWN NOW!!" operation is to hold down the power button 
long enough that a hard power-off happens.  But, I've seen laptops that 
were recalcitrant even with that, and thus it became necessary to pull the 
battery.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

On Fri, 30 Jun 2006, Arnt Gulbrandsen wrote:
> Don't you think the servers on such platforms should deal with it, instead of 
> expecting all clients on all platforms to do so?
> For example, a server on such a platform can fork off another intance of 
> itself (invisible to the client), close the IMAP connection, and let the 
> client go on its way?

That makes no sense.  I said that the server gets a non-maskable kill from 
the OS.  The server has no notice, nor any opportunity to react; it is 
instantly destroyed.

Fortunately, this is rare (and arguably broken) OS behavior.  Most OS 
developers realize that a server should get a proper maskable signal on 
disconnect so that the server can undertake its cleanup action.

The LOGOUT command exists in IMAP for a reason.  Clients which do not send 
the LOGOUT command are broken.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Mark Crispin writes:
> On Fri, 30 Jun 2006, Arnt Gulbrandsen wrote:
>> (When a user closes the lid, the laptop has to sleep right there and 
>> then. Not 30 seconds later.)
>
> Not so!  I've seen sleep-on-lid close take quite a bit longer than 30 
> seconds on some laptops; each running running application must 
> respond to a system sleep event.  To further muddy the waters, a 
> running application has the right to cancel the sleep!

Yes, any laptop vendor can specify most of the timeouts in ACPI, up to 
65534 ms, and OSes can go beyond that limit in many ways. The OSes I 
looked at even give the application some freedom, e.g. asking "how long 
will it take you to save state?". Back when I looked at this, I didn't 
see find case where OS code seriously allowed applications to cancel 
the OS response to events like lid close - the choice was really 
between suspending the nice way or suffer a worse fate when the the 
nice processes are done.

> The only true "SHUT DOWN NOW!!" operation is to hold down the power 
> button long enough that a hard power-off happens.  But, I've seen 
> laptops that were recalcitrant even with that, and thus it became 
> necessary to pull the battery.

(IIRC, that's indicative that some ACPI variable is set to 65535 by the 
vendor, and the OS wedged.)

Arnt

Mark Crispin writes:
> On Fri, 30 Jun 2006, Arnt Gulbrandsen wrote:
>> Don't you think the servers on such platforms should deal with it, 
>> instead of expecting all clients on all platforms to do so?
>> For example, a server on such a platform can fork off another intance 
>> of itself (invisible to the client), close the IMAP connection, and 
>> let the client go on its way?
>
> That makes no sense.  I said that the server gets a non-maskable kill 
> from the OS.  The server has no notice, nor any opportunity to react; 
> it is instantly destroyed.

It has the opportunity to fork when it receives LOGOUT. The fork would 
be finished before the connection close arrives.

Arnt

Mark Crispin wrote:
> On Fri, 30 Jun 2006, Arnt Gulbrandsen wrote:
>> Don't you think the servers on such platforms should deal with it,
>> instead of expecting all clients on all platforms to do so?
>> For example, a server on such a platform can fork off another intance
>> of itself (invisible to the client), close the IMAP connection, and
>> let the client go on its way?
> 
> That makes no sense.  I said that the server gets a non-maskable kill
> from the OS.  The server has no notice, nor any opportunity to react; it
> is instantly destroyed.

The server might have forked and the original process exited to avoid
such behavior, but that would be rather dumb, of course :)

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20060630/2ff39ccb/attachment.sig>

On Fri, 30 Jun 2006, Arnt Gulbrandsen wrote:
> Back when I looked at this, I didn't see find case where OS 
> code seriously allowed applications to cancel the OS response to events like 
> lid close - the choice was really between suspending the nice way or suffer a 
> worse fate when the the nice processes are done.

It must have changed since you last looked at it.  A certain well-known 
financial application from a certain well-known vendor will (for reasons 
that I can not fathom) cancel any attempt to sleep or hiberate; you are 
required to exit the application first.

Also, laptop lid close is a software controllable event, and it can be set 
in the OS to be "ignore completely".

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

On Fri, 30 Jun 2006, Arnt Gulbrandsen wrote:
> It has the opportunity to fork when it receives LOGOUT. The fork would be 
> finished before the connection close arrives.

That is beside the point.  The problem is with clients that don't even 
send a LOGOUT.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

On Fri, 30 Jun 2006, Jan Kundrt wrote:
> The server might have forked and the original process exited to avoid
> such behavior, but that would be rather dumb, of course :)

The process that is using the socket gets the kill.  So the server has to 
fork, the fork has to somehow stay in communication with its parent but 
not get hit by the kill, and yet still have control over the necessary 
resources to clean up...  And of course this has to be verified against 
the OS that does the kill.

All just so some poorly-written client can avoid obeying the IMAP 
protocol.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.