Diferencia entre revisiones de «Mensajería»

Revisión del 18:38 15 nov 2011

Un mensaje es un contenedor de información en un cierto formato que se intercambia entre dos o más procesos.

Mediante los mensajes podemos transmitir información y sincronizar procesos (mediante la espera de un cierto mensaje).

Los sistemas operativos generalmente ofrecen dos llamadas al sistema (o primitivas básicas) para los procesos, enviar y recibir mensajes:

• send (mensaje): Para enviar un mensaje
• receive (mensaje): Para recibir un mensaje

Destino y fuente

Para identificar la fuente y el destino de nuestro mensaje se pueden emplear dos estrategias.

Denominación Directa

En este caso se emplea un ID que permite identificar a la fuente y al destinatario de manera unívoca en el sistemas, por ejemplo, el PID de un proceso. La denominación directa permite tres configuraciones:

• • Unicast, de manera que la comunicación sucede entre una fuente y un destinatario.
  • Broadcast, el emisor envía un mensaje a todos los procesos existentes en el sistema.
  • Multicast, el emisor envía un mensaje a un grupo de procesos, siendo un grupo un subconjunto de procesos existentes en el sistema. El sistema operativo debe ofrecer llamadas al sistema que permitan a los procesos crear grupos y suscribirse a ellos.

Denominación Indirecta

Se emplea un elemento intermediario denominado buzón. El sistema operativo ofrece llamadas al sistema que permiten la creación y destrucción de buzones, por ejemplo, CreateMailbox y DestroyMailbox. Una vez creado el buzón, se emplea éste para realizar la comunicación entre procesos.

El sistema operativo debe de comprobar que la identidad de la fuente de un mensaje es correcta, de lo contrario un proceso podría suplantar la identidad de otro.

Formas de transmisión

• Transmisión por copia
  • Directa: el mensaje se copia de espacio de emisor a espacio de receptor.
  • Indirecta: el mensaje se copia de espacio de emisor a espacio (buzón) de SO, y de ahí a espacio de receptor.

• Transmisión por referencia
  • Directa: lo que se copia es un puntero al mensaje
  • Global: el emisor crea mensaje en espacio de SO, y se copia a espacio de receptor un puntero al mismo.

• Transmisión por copia de escritura: el mensaje sólo se copia si se modifica por emisor o receptor.

Formas de comunicación

• Comportamiento del emisor, send()
  • Síncrona: el proceso emisor que realiza el send() queda bloqueado hasta que el receptor llama a recv()
  • Asíncrona: suponemos una estructura de datos con capacidad de almacenamiento limitada, dependiente del proceso destinatario o en el buzón del SO. Al ser enviados, los mensajes irán encolándose para que el proceso receptor pueda gestionarlos cuando pueda. De esta manera se aumenta el rendimiento pero se requiere de políticas adicionales de tratamiento de los mensajes si la capacidad de almacenamiento de la estructura de datos se ve sobrepasada(PE, eliminación de mensajes, realocalización de memoria, etc..)

• Comportamiento del receptor, recv()
  • Bloqueante: una llamada a recv() sin mensajes a procesar pasa el proceso llamante a estado bloqueado. Un send() de otro proceso que añada un mensaje a la cola del proceso bloqueado hace que éste pase a estado preparado.
  • No bloqueante: una llamada a recv() sin mensajes a procesar devuelve un mensaje de error, pero la ejecución del proceso llamante continúa.

Formato de los mensajes

Fijo

Los procesos acuerdan emplear un formato fijo para sus mensajes.

Ejemplo: Simple Network Time Protocol.<ref> Véase http://tools.ietf.org/html/rfc4330, sección 4, Message Format.</ref>

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9  0  1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |LI | VN  |Mode |    Stratum    |     Poll      |   Precision    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Root  Delay                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Root  Dispersion                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Reference Identifier                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                                |
     |                    Reference Timestamp (64)                    |
     |                                                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                                |
     |                    Originate Timestamp (64)                    |
     |                                                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                                |
     |                     Receive Timestamp (64)                     |
     |                                                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                                |
     |                     Transmit Timestamp (64)                    |
     |                                                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Key Identifier (optional) (32)                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                                |
     |                                                                |
     |                 Message Digest (optional) (128)                |
     |                                                                |
     |                                                                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Variable

• Type-Length-Value

Ejemplo: Usado en Netlink para la codificación de atributos de un mensaje.<ref>Ver Communicating between the kernel and user-space in Linux using Netlink Sockets (http://1984.lsi.us.es/~pablo/docs/spae.pdf)</ref>

• Text-based human-readable.

1. Comma-Separated Value (CSV). http://en.wikipedia.org/wiki/Comma-separated_values
2. Extensible Markup Language (XML). http://en.wikipedia.org/wiki/XML
3. JavaScript Object Notation (JSON). http://en.wikipedia.org/wiki/JSON

Mixto

Los procesos acuerdan emplear mensaje con partes cuyo formato es fijo, como por ejemplo una cabecera inicial, seguido de partes de tamaño variable.

Ejemplo: Internet Protocol (IPv4).<ref>Ver http://www.ietf.org/rfc/rfc791.txt, sección 3.1.</ref>

   0                   1                   2                   3   
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Version|  IHL  |Type of Service|          Total Length         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         Identification        |Flags|      Fragment Offset    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Time to Live |    Protocol   |         Header Checksum       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                       Source Address                          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Destination Address                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Options                    |    Padding    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  /                                                               /
  /                         Payload                               /
  /                                                               /
  /////////////////////////////////////////////////////////////////

Mensajería a través de la red

• Unidad del destinatario
• Fiabilidad en la transmisión
• Formato de los datos (http://www.cs.umd.edu/class/sum2003/cmsc311/Notes/Data/endian.html): Enviar un entero a través de la red puede ser un problema debido a la forma en el que se representan los datos en la memoria dependiente de la arquitectura. Por ejemplo, un PC con arquitectura Intel x86 emplea formato little-endian, mientras que un SPARC de Sun Microsystems (ahora Oracle) emplea big-endian.

• • Little Endian: Bytes menos significativo al principio.

int main(void)
{
        int a = 10, i;
        char *p = &a;

        for (i=0; i<sizeof(a); i++) {
                printf("posición %d: %.2x\n", i, p[i]);
        }
}

Muestra el siguiente resultado en un PC:

posición 0: 0a (n+3)
posición 1: 00 (n+2)
posición 2: 00 (n+1)
posición 3: 00 (n)

• • Big Endian: Bytes menos significativo al final.

posición 0: 00 (n)
posición 1: 00 (n+1)
posición 2: 00 (n+2)
posición 3: 0a (n+3)

En Internet se sigue la convención de expresar datos en Big Endian, habría que hacer la conversión. Habría que usar ntohl (network to host long).

En little-endian, la implementación de ntohl es la siguiente:

1. define __constant_ntohl(x) ___constant_swab32((__be32)(x)

Ver /usr/include/linux/byteorder/little_endian.h

mientras que en big-endian es:

1. define __constant_ntohl(x) ((__u32)(__be32)(x))

Si empleamos formato textuales, como CSV, XML o JSON, que codifican la información en bytes, no tenemos este problema.

Referencias

<references/>