Member of The Internet Defense League Últimos cambios
Últimos Cambios
Blog personal: El hilo del laberinto Geocaching

El modo servidor (was: Qpopper 2.52: Another bug in the bulletins code)

Última Actualización: 17 de Agosto de 1.998 - Lunes 

Message-ID: <35D812F7.BE6DF235@argo.es>
Date: Mon, 17 Aug 1998 11:24:39 +0000
From: "Jesús Cea Avión" <jcea@argo.es>
To: hacking@argo.es,
        Lista de Proveedores Internet <proveedores@listserv.rediris.es>,
        Lista proveedores QMD <proveedores_qmd@syntax-error.org>,
        teleco-vigo@argo.es,
        "Grupo de Desarrollo Informático" <gdi@uvigo.es>,
        anita@argo.es
Subject: El modo servidor (was: Qpopper 2.52: Another bug in the bulletins code)

He recibido media docena de mensajes solicitando información sobre el "server mode" del Qpopper, por lo que envío este mensaje de respuesta global.

En mi mensaje anterior, describiendo el bug del qpopper, comentaba que para que el fallo se produzca es necesario, entre otras cosas, el compilar el servidor con la opción "server mode". Además señalaba que dicho modo es "casi obligado" si eres un ISP. En este mensaje describiré qué es el "server mode" y por qué resulta necesario.

Antes de nada comentar que el "server mode" y su utilidad me fue señalado por primera vez por Adria García (AKA "Manolete"), como una de las razones para *no* utilizar el Qpopper en favor de otras versiones POP. Yo le hice notar que hace mucho que Qualcomm incorpora dicho modo en su servidor, al menos según la documentación. Ese fue mi primer contacto con el tema.

El protocolo POP permite que un usuario lea su buzón de correo. Normalmente los pasos que sigue el servidor POP son:

  1. Bloqueo del buzón de correo del usuario. Cualquier mensaje que llegue para él esperará en el spool. Este bloqueo dura sólo unos instantes (pocos segundos).

  2. El buzón del usuario se copia en otro sitio/con otro nombre. Todas las funciones POP se realizarán sobre esa copia temporal.

  3. El buzón original se borra y se desbloquea, para permitir la recepción de nuevos mensajes durante la transferencia de los antiguos al usuario.

  4. Una vez que el usuario termina sus actividades POP, el servidor bloquea de nuevo el buzón del usuario y "mezcla" su contenido actual con lo que el usuario haya dejado sin borrar en su buzón temporal POP.

Este sistema, como puede verse, tiene tres problemas:

  1. Realiza un copiado del buzón del usuario. Ello hace, entre otras cosas, que durante unos instantes un usuario consuma el doble de recursos. Por ejemplo, si el usuario tiene cuatro megabytes de correo pendiente, durante la copia y mientras ésta no termina y se borra el buzón original, el usuario llega a ocupar ocho megabytes. El proceso de copia, además, supone tiempo, consumo de CPU y consumo de disco.

  2. Si el usuario simplemente abre su cuenta POP para comprobar que existe correo, sin leerlo ni borrarlo (el típico chequeo de correo que realiza Netscape o el Internet Explorer), el servidor copiará su buzón para, seguidamente, devolverlo a su estado original, sin modificaciones. Evidentemente ello supone un consumo de recursos innecesario.

  3. Si el usuario lee completamente su correo y lo borra (lo normal), nos podemos ahorrar el proceso de "mezcla" final entre el buzón real y su copia temporal, ya que ésta estará vacía.

El modo "servidor" intenta eliminar todos estos problemas, basándose en la suposición de que los mensajes solo llegan al buzón a través del Sendmail y solo son leidos a través de POP. Esto, como todos sabemos, es lo más normal en un ISP.

Si es el caso, y si compilamos el servidor POP en modo "servidor", los pasos son los siguientes cuando un usuario intenta leer su correo:

  1. Bloqueo del buzón de correo del usuario. Cualquier mensaje que llegue para él esperará en el spool. Este bloqueo dura sólo unos instantes.

  2. El servidor POP repasa el buzón, y anota el número de mensajes en el mismo, así como el final de fichero.

  3. El servidor POP desbloquea el buzón.

  4. Todas las peticiones POP son procesadas sobre el mismo buzón del usuario. Así mismo, los mensajes nuevos que vayan entrando se almacenarán al final del buzón.

  5. Cuando el usuario cierra la sesión POP, pueden pasar tres cosas:

    1. El usuario no ha borrado ni leído ningún mensaje: El sistema POP no necesita tocar el buzón del usuario para nada.

    2. El usuario ha leído pero no ha borrado mensajes: El sistema POP actualiza el buzón para marcar los mensajes como leídos. La actualización es muy eficiente cuando no se ha recibido ningún mensaje nuevo.

    3. El usuario ha leído y borrado todos sus mensajes: si no se ha recibido ningún mensaje nuevo, el servidor simplemente borra todo el buzón.

Por tanto vemos que el modo "servidor":

  • Evita la copia innecesaria de buzones.

  • Está optimizado para los dos casos más comunes:

    • Chequeos de correo, sin lectura del mismo.
    • Lectura completa del buzón.

De cara al proveedor, supone un consumo mucho menor de disco y CPU. De cara al usuario, se evita esos segundos de espera que se producían cuando tenía varios megabytes de email esperando.

Espero que su utilidad y su "conveniencia" en el mundo ISP esté clara :). 

-- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea@argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
                                      _/_/    _/_/          _/_/_/_/_/
PGP Key Available at KeyServ   _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibnitz

Python Zope ©1998 jcea@jcea.es

Más información sobre los OpenBadges

Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS