Mensajería
Un mensaje es un contenedor que se emplea para intercambiar información entre dos o más procesos. Los mensajes tienen un cierto formato generalmente compuesto por una cabecera, que contiene información sobre la fuente y el destinatario, y un cuerpo, que contiene información específica.
Los mecanismos de mensajería se refiere al conjunto de funcionalidades que permiten al sistema operativo realizar la entrega de un mensaje a uno o varios procesos. Mediante dicho mecanismo también es posible resolver problemas de concurrencia.
Los sistemas operativos generalmente ofrecen dos llamadas al sistema para que un proceso pueda enviar y recibir mensajes:
- send(mensaje, destino): Para enviar un mensaje
- recv(mensaje)': Para recibir un mensaje
Cualquier proceso que necesita comprobar si tiene mensajes para ser procesados por él debe invocar la llamada al sistema recv.
Contenido
Formas de identificación
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 sistema, 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. Un proceso puede suscribirse a tantos grupos como le sea necesario.
El principal inconveniente de la denominación directa es que se pierde el mensaje si el destino no se encuentra.
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
Distinguimos tres formas de transmisión: Transmisión por copia, transmisión por referencia y transmisión por copia en caso de escritura.
Transmisión por copia
Si se emplea denominación directa, al invocar el receptor la llamada recv, el mensaje se copia de espacio de memoria del emisor al espacio de receptor. Esta forma de implementar la transmisión tiene un coste de orden lineal <math>O(n)</math>.
Si se emplea denominación indirecta, al invocar send el emisor, el mensaje se copia del espacio de emisor al espacio del buzón, que se encuentra en el espacio de memoria del sistema operativo. Una vez que el receptor invoca receive, se copia el mensaje al espacio de memoria que el receptor ha habilitado para almacenar el mensaje.
Transmisión por referencia
Es una mejora frente al mecanismo de transmisión por copia. Básicamente, en lugar de copiar el mensaje, lo que supone un coste de <math>O(n)</math>, se le devuelve al receptor una dirección de memoria en la que se encuentra el mensaje, lo que supone únicamente 4 u 8 bytes dependiendo del tamaño de palabra del procesador (si es de 32-bits o 64-bits).
Si se emplea junto a la denominación directa, el sistema operativo le devuelve al receptor un puntero a la dirección en la que se encuentra el mensaje. Si el mensaje está en el espacio del emisor, son necesarios mecanismos explícitos de compartición de memoria entre procesos, ya que dos procesos cualquiera no comparten memoria. Si el mensaje está en el espacio del sistema operativo, éste debe ofrecer a los procesos mecanismos para acceder a su espacio de memoria-
Si se emplea junto a la denominación indirecta, el emisor crea un mensaje en el espacio del sistema operativo y se le ofrece un puntero al receptor.
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.
Entendemos por proceso llamante a aquel que hace uso de las llamadas send() y recv().
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>
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Length | Type | ||||||||||||||||||||||||||||||
| Value |
- Text-based human-readable.
- Comma-Separated Value (CSV). http://en.wikipedia.org/wiki/Comma-separated_values
- Extensible Markup Language (XML). http://en.wikipedia.org/wiki/XML
- 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
- Unicidad 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:
- define __constant_ntohl(x) ___constant_swab32((__be32)(x)
Ver /usr/include/linux/byteorder/little_endian.h
mientras que en big-endian es:
- 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/>
