b'\n_START_ARTICLE_\nPaso de mensajes\n_START_PARAGRAPH_\nEn ciencias de la computaci\xc3\xb3n, el paso de mensajes es un paradigma de programaci\xc3\xb3n ampliamente usado en el software moderno. Sus aplicaciones cubren un amplio campo, y puede usarse desde para garantizar que los diferentes objetos que constituyen un programa inform\xc3\xa1tico puedan trabajar de forma coherente entre ellos hasta para permitir que una tarea pueda ejecutarse de forma sincronizada entre varios ordenadores. Es uno de los conceptos clave en modelos de programaci\xc3\xb3n concurrente, programaci\xc3\xb3n distribuida y programaci\xc3\xb3n orientada a objetos._NEWLINE_De forma abstracta, se llama mensaje a una porci\xc3\xb3n de informaci\xc3\xb3n que un proceso emisor env\xc3\xada a un destinatario (El cual puede ser otro proceso, un actor o un objeto). El modelo de paso de mensajes es el que define los m\xc3\xa9todos y funciones para poder llevar a cabo el env\xc3\xado de un mensaje de un proceso emisor a un destinatario. Supone un enfoque opuesto al paradigma tradicional en el cual los procesos, funciones y subrutinas s\xc3\xb3lo pod\xc3\xadan ser llamados directamente a trav\xc3\xa9s de su nombre.\n_START_SECTION_\nIntroducci\xc3\xb3n\n_START_PARAGRAPH_\nEl paso de mensajes es una t\xc3\xa9cnica que se usa para, desde un proceso, invocar de forma abstracta un comportamiento concreto por parte de otro actor (Por ejemplo, ejecutar una funci\xc3\xb3n o un programa). Esto supone un gran cambio con respecto al modelo tradicional en el cual se llamaba a los programas y funciones s\xc3\xb3lo por su nombre, el paso de mensajes constituye un mecanismo esencial para distinguir una funci\xc3\xb3n de su implementaci\xc3\xb3n interna\xe2\x80\x94 El emisor env\xc3\xada un mensaje solicitando una acci\xc3\xb3n abstracta al destinatario, y es el destinatario el que, al recibir el mensaje, decidir\xc3\xa1 la acci\xc3\xb3n que debe ejecutar para cumplir la petici\xc3\xb3n._NEWLINE_Entre las ventajas que proporciona este mecanismo destacan el alto nivel de encapsulamiento y la distribuci\xc3\xb3n. En programaci\xc3\xb3n, la filosof\xc3\xada de encapsular la informaci\xc3\xb3n consiste en que los objetos software deben poder invocar servicios a otros objetos, sin tener por qu\xc3\xa9 conocer ni preocuparse ni de c\xc3\xb3mo ni de qu\xc3\xa9 manera est\xc3\xa1 implementada en su interior la resoluci\xc3\xb3n de dicha demanda. Esto deriva en un c\xc3\xb3digo m\xc3\xa1s limpio, corto y f\xc3\xa1cil de comprender y mantener.\n_START_SECTION_\nCaso pr\xc3\xa1ctico en programaci\xc3\xb3n orientada a objetos\n_START_PARAGRAPH_\nUn ejemplo cl\xc3\xa1sico de aplicaci\xc3\xb3n del modelo de paso de mensajes podr\xc3\xada ser en el \xc3\xa1mbito de la inform\xc3\xa1tica gr\xc3\xa1fica. Por ejemplo, si el programador est\xc3\xa1 creando un programa que trabaja con diversos tipos de formas geom\xc3\xa9tricas de una clase Forma, el programa contendr\xc3\xa1 varios objetos instancias de dicha clase, como por ejemplo cuadrado, rombo o triangulo._NEWLINE_Imaginemos el caso en que el programador desea conocer el \xc3\xa1rea de los objetos de la clase Forma declarados. Como el c\xc3\xa1lculo del \xc3\xa1rea de dichas formas no es el mismo para todas y cada una tendr\xc3\xa1 un algoritmo matem\xc3\xa1tico distinto para calcularla, en un modelo tradicional el programador se ver\xc3\xada obligado a crear una estructura condicional IF-ELSE que consultase una a una el tipo de forma de cada objeto para ejecutar la operaci\xc3\xb3n matem\xc3\xa1tica correspondiente._NEWLINE_En lugar de eso, en el modelo de paso de mensajes el programador simplemente debe enviar un mensaje a cada objeto consultando su \xc3\xa1rea, y ser\xc3\xada la implementaci\xc3\xb3n interna de la clase Forma la que se encargar\xc3\xada de escoger y calcular de forma correcta dicho dato. El objeto responder\xc3\xada a la petici\xc3\xb3n enviando de vuelta otro mensaje al destinatario con el \xc3\xa1rea resultante del c\xc3\xa1lculo. _NEWLINE_Como es natural, para que esto sea posible, la clase destinataria debe tener implementado previamente un m\xc3\xa9todo por el cual pueda interpretar los mensajes de forma normalizada, as\xc3\xad como las funciones necesarias para llevar a cabo el c\xc3\xa1lculo del \xc3\xa1rea.\xe2\x80\x8b\n_START_SECTION_\nCaso pr\xc3\xa1ctico en programaci\xc3\xb3n concurrente y distribuida\n_START_PARAGRAPH_\nOtra de las aplicaciones donde este modelo supone una clara ventaja es en la programaci\xc3\xb3n concurrente y distribuida. En los casos en los que tengamos varios procesos ejecut\xc3\xa1ndose en un mismo o en diferentes ordenadores con caracter\xc3\xadsticas y velocidad de trabajo dispares y estos procesos requieran comunicarse entre ellos para poder cumplir su funci\xc3\xb3n, el paso de mensajes entre ellos es una de las formas m\xc3\xa1s ampliamente aceptadas de mantener una sincronizaci\xc3\xb3n constante y coherente entre ellos. Una de las aplicaciones m\xc3\xa1s conocidas es internet, donde una red de ordenadores dispares se comunican entre ellos para intercambiar datos en diferentes lugares y momentos. _NEWLINE_El protocolo m\xc3\xa1s extendido para acceder a p\xc3\xa1ginas web \xe2\x80\x94 HTTP \xe2\x80\x94 tambi\xc3\xa9n funciona bajo este modelo: en su caso, un ordenador al que se conoce como "servidor" contiene un dato (por ejemplo, una p\xc3\xa1gina web), y varios ordenadores independientes (llamados "clientes") desean acceder a dicho dato. Para llevar a cabo dicho prop\xc3\xb3sito se produce un intercambio de mensajes normalizados cliente-servidor: En primer lugar el cliente debe enviar un mensaje al servidor informando de que desea acceder a un dato concreto de los que \xc3\xa9l tiene. El servidor recibe y ejecuta por su lado el c\xc3\xb3digo necesario para llevar a cabo la petici\xc3\xb3n. A continuaci\xc3\xb3n, el servidor responde al cliente mediante el paso de otro mensaje, otorg\xc3\xa1ndole el dato (en este caso, la p\xc3\xa1gina web) que ha solicitado._NEWLINE_Uno de los est\xc3\xa1ndares de paso de mensajes m\xc3\xa1s ampliamente utilizados en programaci\xc3\xb3n concurrente y distribuida es MPI (Message Passing Interface).\n_START_SECTION_\nPaso de mensajes s\xc3\xadncrono y as\xc3\xadncrono\n_START_PARAGRAPH_\nUna de las cuestiones m\xc3\xa1s importantes en el paso un mensaje es diferenciar si el env\xc3\xado y recepci\xc3\xb3n se produce de forma s\xc3\xadncrona o as\xc3\xadncrona. Para comprender esto, primero es necesario resaltar que el env\xc3\xado y recepci\xc3\xb3n de un mensaje constituyen dos pasos completamente diferentes: por un lado, el proceso emisor ejecuta la funci\xc3\xb3n que env\xc3\xada el mensaje al proceso destinatario, y este ejecutar\xc3\xa1 por su parte otra funci\xc3\xb3n que le permitir\xc3\xa1 recibirlo._NEWLINE_Se dice que el paso de mensajes es s\xc3\xadncrono cuando el env\xc3\xado y la recepci\xc3\xb3n del mensaje se producen en un mismo instante de tiempo para ambos procesos. En el caso de que el env\xc3\xado por parte del emisor del mensaje y la recepci\xc3\xb3n de este por parte del destinatario se produzcan en instantes de tiempo diferentes, decimos que el paso de mensajes es as\xc3\xadncrono.\n_START_SECTION_\nSeguridad\n_START_PARAGRAPH_\nUn concepto fundamental relacionado con la diferencia entre el paso s\xc3\xadncrono y as\xc3\xadncrono es la seguridad del paso del mensaje. El paso de un mensaje es seguro cuando podemos garantizar que el mensaje que recibe el destinatario es el mismo que env\xc3\xada el emisor, y que no se ha producido ninguna alteraci\xc3\xb3n del contenido del mensaje durante el lapso de tiempo que transcurre entre el env\xc3\xado y la recepci\xc3\xb3n. El env\xc3\xado s\xc3\xadncrono siempre es seguro, m\xc3\xa1s el env\xc3\xado as\xc3\xadncrono no es seguro en s\xc3\xad mismo, por lo que en ese caso es el programador el responsable de garantizar la integridad del mensaje.\n_START_SECTION_\nPaso de mensajes s\xc3\xadncrono\n_START_PARAGRAPH_\nEn el paso de mensajes s\xc3\xadncrono, el proceso emisor en primer lugar ejecutar\xc3\xa1 la funci\xc3\xb3n de env\xc3\xado s\xc3\xadncrono (Por ejemplo, en MPI: s_send()). Tras ese momento dicho proceso detendr\xc3\xa1 su ejecuci\xc3\xb3n en ese punto y se quedar\xc3\xa1 bloqueado a la espera de que el proceso receptor reciba el mensaje. Cuando el proceso receptor llega a la instrucci\xc3\xb3n en la cual se le ordena que reciba el mensaje (receive()), entonces comienza la transmisi\xc3\xb3n del mensaje por parte de ambos. Ambos procesos permanecer\xc3\xa1n bloqueados hasta que la transmisi\xc3\xb3n del mensaje haya finalizado correctamente. Cuando suceda, ambos ser\xc3\xa1n desbloqueados y podr\xc3\xa1n continuar cada uno ejecutando su c\xc3\xb3digo. En el caso de que el programa receptor llegue a la instrucci\xc3\xb3n de recibir antes de que el emisor haya llegado a su instrucci\xc3\xb3n de enviar el mensaje, el receptor se quedar\xc3\xa1 bloqueado a la espera del emisor._NEWLINE_El paso de mensajes s\xc3\xadncrono siempre es seguro, ya que el bloquearse ambos procesos hasta que la recepci\xc3\xb3n finaliza, podemos garantizar que no hay posibilidad de que el mensaje haya podido ser alterado. Sin embargo, el sistema, a pesar de ser sencillo de programar tiene el inconveniente de ser poco flexible: Ambos procesos deben "citarse", es decir, deben esperar hasta que ambos est\xc3\xa9n en el mismo punto de su c\xc3\xb3digo para poder realizar el mensaje. Como no podemos garantizar que el tiempo que transcurrir\xc3\xa1 entre que el emisor llegue a su instrucci\xc3\xb3n s_send() y el receptor llegue a su instrucci\xc3\xb3n receive() sea razonable, este m\xc3\xa9todo en algunos casos podr\xc3\xada ver mermado el rendimiento del conjunto de ambos. _NEWLINE_Por otro lado, una mala programaci\xc3\xb3n podr\xc3\xada llevar a que un proceso ejecutara una funci\xc3\xb3n de env\xc3\xado que no tiene su correspondiente funci\xc3\xb3n de recibir o viceversa, con lo cual los procesos podr\xc3\xadan llegar a quedar bloqueados indefinidamente esperando el uno al otro (interbloqueo).\n_START_SECTION_\nPaso de mensajes as\xc3\xadncrono\n_START_PARAGRAPH_\nEl env\xc3\xado as\xc3\xadncrono es aquel en que los procesos no necesitan ser "citados" para que se produzca el env\xc3\xado del mensaje. Es decir, cuando el emisor llega a la instrucci\xc3\xb3n en la que se produce el env\xc3\xado, no se bloquea a la espera de que el programa destinatario llegue a la instrucci\xc3\xb3n en que lo recibe, sino que sigue ejecutando su c\xc3\xb3digo con normalidad. Por su parte, el programa receptor podr\xc3\xa1 recibir el mensaje en cualquier momento posterior al env\xc3\xado sin frenar por ello al emisor hasta que esto se produzca. Una vez m\xc3\xa1s, si el receptor ha llegado a una orden de recepci\xc3\xb3n de mensaje pero el emisor a\xc3\xban no ha enviado nada, el receptor s\xc3\xad se bloquear\xc3\xa1 a la espera de que el emisor lleve a cabo el env\xc3\xado._NEWLINE_El que el emisor no quede bloqueado tras enviar el mensaje es una ventaja con respecto a la eficiencia general del sistema, pero puede conllevar un riesgo de seguridad en el paso del mensaje. Por ejemplo, pongamos el caso de que el proceso emisor tiene una variable local n = 2 y desea enviar el contenido de esta variable a un proceso receptor. El proceso ejecutar\xc3\xa1 su instrucci\xc3\xb3n de env\xc3\xado de la variable y continuar\xc3\xa1 su c\xc3\xb3digo con normalidad. Al no poder conocer cuanto tiempo transcurrir\xc3\xa1 hasta que el receptor reciba la variable, podr\xc3\xada suceder que desde que el emisor ejecut\xc3\xb3 la orden de env\xc3\xado y hasta que se produjo la recepci\xc3\xb3n, el c\xc3\xb3digo del emisor ha alterado el contenido de la variable (incluso podr\xc3\xada suceder que ya la hubiese eliminado) n, por lo que no podemos garantizar la seguridad del env\xc3\xado al no poder afirmar que el emisor recibir\xc3\xa1 el valor que realmente se quer\xc3\xada enviar, el 2.\n_START_SECTION_\nEnv\xc3\xado as\xc3\xadncrono seguro\n_START_PARAGRAPH_\nHabitualmente, los est\xc3\xa1ndares incluyen un mecanismo de paso de mensajes que, siendo as\xc3\xadncrono, garantiza la seguridad del env\xc3\xado. Para ello, el emisor ejecuta la funci\xc3\xb3n correspondiente (send()), copia los datos en un lugar seguro para evitar que estos se puedan alterar, y a continuaci\xc3\xb3n contin\xc3\xbaa su ejecuci\xc3\xb3n con normalidad. En el momento en que el proceso receptor ejecute su orden para recibir el mensaje (receive()), recibir\xc3\xa1 el dato que el emisor copi\xc3\xb3 en su momento en un lugar seguro, por lo que se garantiza que este dato no ha sido alterado durante el tiempo transcurrido.\n_START_SECTION_\nEnv\xc3\xado as\xc3\xadncrono inseguro\n_START_PARAGRAPH_\nAdem\xc3\xa1s de las funciones de env\xc3\xado as\xc3\xadncrono seguro, las interfaces de paso de mensajes tambi\xc3\xa9n suelen incorporar funciones que permitan pasar mensajes de forma insegura. En su caso, el proceso emisor ejecutar\xc3\xa1 la orden de env\xc3\xado inseguro (i_send()), se dar\xc3\xa1 la orden de env\xc3\xado e instant\xc3\xa1neamente se devolver\xc3\xa1 el control al programa principal, sin esperar a que los bytes hayan terminado de ser le\xc3\xaddos del emisor ni escritos en el receptor. Por su parte, el receptor ejecutar\xc3\xa1 la orden de recepci\xc3\xb3n insegura (i_send), por lo que se dar\xc3\xa1 la orden de recepci\xc3\xb3n y a continuaci\xc3\xb3n se devolver\xc3\xa1 el control al programa, sin esperar a que se complete el env\xc3\xado ni a que terminen de llegar los datos._NEWLINE_En este caso, el responsable de garantizar manualmente la integridad del mensaje es el programador. Las interfaces de paso de mensajes incorporan una serie de funciones que permiten al programador sondear el estado del paso del mensaje y actuar en consecuencia. Concretamente, se dispone de funciones de sondeo bloqueante (wait_send() y wait_recv()), las cuales bloquean al emisor y receptor respectivamente si el env\xc3\xado o recepci\xc3\xb3n del mensaje no ha finalizado a\xc3\xban. El programador tambi\xc3\xa9n dispone de funciones de sondeo no bloqueante (test_send() y test_recv()) que permiten conocer este mismo hecho sin bloquear a ninguno de los procesos, simplemente devolviendo un valor booleano para que sea el programador el que decida la acci\xc3\xb3n a tomar en cada caso.'