2010-03-25 22 views
10

Digamos que estoy usando IMAP IDLE para controlar los cambios en una carpeta de correo.IMAP Idle Timeout

La especificación IMAP dice que las conexiones IDLE solo deberían permanecer activas durante 30 minutos como máximo, pero se recomienda seleccionar un número menor de minutos, digamos 20 minutos, luego cancelar la inactividad y reiniciar.

Me pregunto qué pasaría si el contenido del correo cambiara entre la cancelación inactiva y la nueva inactividad que se está creando. Un correo electrónico podría perderse. Dado que RECIENTE es un poco vago, esto podría llevar a obtener una lista de mensajes antes de que termine el antiguo inactivo, y se inicie una nueva inactividad.

Pero esto es casi lo mismo que un sondeo cada 20 minutos, y anula algunas de las ventajas de la inactividad.

Alternativamente, una nueva sesión inactiva podría iniciarse antes de finalizar la que está por caducar.

Pero en cualquier caso, creo que este problema ya se ha resuelto, así que aquí estoy pidiendo recomendaciones.

Gracias,

Paul

Respuesta

21

Como saben, el propósito de comando IDLE de IMAP (RFC 2177) es para que sea posible tener las actualizaciones de estado del servidor de transmisión al cliente en tiempo real. En este contexto, actualizaciones de estado significa respuestas de servidor IMAP sin etiquetar como EXISTS, RECIENT, FETCH o EXPUNGE que se envían cuando llegan mensajes nuevos, el estado del mensaje se actualiza o se elimina un mensaje.

Sin embargo, estas actualizaciones de estado IMAP pueden ser devueltos por cualquier comando de IMAP, no sólo el comando IDLE - por ejemplo, el comando NOOP (ver RFC 3501 la sección 6.1.2) se puede utilizar para sondear las actualizaciones del servidor también (es anterior al comando IDLE). IDLE solo hace posible obtener estas actualizaciones de manera más eficiente: si no utiliza el comando IDLE, las actualizaciones de servidor simplemente serán enviadas por el servidor cuando el cliente ejecuta otro comando (o incluso cuando no hay ningún comando en progreso en algunos casos)) - vea RFC 3501 sección 5.2 y 5.3 para más detalles.

Esto significa que si se cambia un mensaje entre el IDLE cancelación y el nuevo comando IDLE, las actualizaciones de estado no deben perderse, al igual que no se pierden si nunca Inactivo en el primer lugar (y el uso NOOP cada pocos segundos, por ejemplo); simplemente deben enviarse después de que se inicie el nuevo comando IDLE.

0

Otro enfoque sería recordar el último uid más alto de la carpeta que se está supervisando. Cada vez que piense que hay posibilidades de que se haya perdido la actualización. Haga una búsqueda de la siguiente manera: *