Los flujos de datos distribuidos tienen un propósito análogo a las variables o parámetros de métodos en lenguajes de programación como Java , en el sentido de que pueden representar el estado almacenado o comunicado por una capa de software. A diferencia de las variables o parámetros, que representan una unidad de estado que reside en una única ubicación, los flujos distribuidos son dinámicos y distribuidos: aparecen simultáneamente en múltiples ubicaciones dentro de la red al mismo tiempo. Como tal, los flujos distribuidos son una forma más natural de modelar la semántica y el funcionamiento interno de ciertas clases de sistemas distribuidos. En particular, la abstracción del flujo de datos distribuidos se ha utilizado como una forma conveniente de expresar las relaciones lógicas de alto nivel entre partes de protocolos distribuidos. [1] [2] [3]
Propiedades informales
Un flujo de datos distribuido satisface las siguientes propiedades informales.
Asíncrono , sin bloqueo y unidireccional . Cada evento representa una única instancia de invocación de método asincrónico , unidireccional y sin bloqueo u otra forma de mensaje explícito o implícito que pasa entre dos capas o componentes de software. Por ejemplo, cada evento podría representar una única solicitud para multidifusión de un paquete , emitida por una capa de aplicación a un protocolo de multidifusión subyacente . El requisito de que los eventos sean unidireccionales y asincrónicos es importante. Las invocaciones de métodos que pueden devolver resultados normalmente se representarían como dos flujos separados: un flujo que representa las solicitudes y otro flujo que representa las respuestas. [4] [5]
Homogéneo , unidireccional y uniforme . Todos los eventos del flujo distribuido tienen el mismo propósito funcional y lógico y están relacionados entre sí; generalmente, requerimos que representen llamadas a métodos o intercambios de mensajes entre instancias de las mismas capas funcionales , o instancias de los mismos componentes , pero quizás en diferentes nodos dentro de una red informática . Además, todos los eventos deben fluir en la misma dirección (es decir, un tipo de capa o componente siempre produce y el otro siempre consume los eventos) y transportar el mismo tipo de carga útil . Por ejemplo, un conjunto de eventos que incluye todas las solicitudes de multidifusión emitidas por la misma capa de aplicación al mismo protocolo de multidifusión es un flujo distribuido. Por otro lado, un conjunto de eventos que incluye solicitudes de multidifusión realizadas por diferentes aplicaciones a diferentes protocolos de multidifusión no se consideraría un flujo distribuido, y tampoco lo sería un conjunto de eventos que representen solicitudes de multidifusión, así como reconocimientos y notificaciones de errores. [4] [6]
Concurrente , continuo y distribuido . El flujo generalmente incluye todos los eventos que fluyen entre las dos capas de software, simultáneamente en diferentes ubicaciones y durante un período de tiempo finito o infinito. Así, en general, los eventos en un flujo distribuido se distribuyen tanto en el espacio (ocurren en diferentes nodos) como en el tiempo (ocurren en diferentes momentos). Por ejemplo, el flujo de solicitudes de multidifusión incluiría todas las solicitudes realizadas por instancias de la aplicación determinada en diferentes nodos; normalmente, dicho flujo incluiría eventos que ocurren en todos los nodos que participan en el protocolo de multidifusión dado. Un flujo en el que todos los eventos ocurren en el mismo nodo se consideraría degenerado. [3] [5]
Representación formal
Formalmente, representamos cada evento en un flujo distribuido como un cuádruple de la forma (x,t,k,v), donde x es la ubicación (por ejemplo, la dirección de red de un nodo físico) en la que ocurre el evento, t es el momento en que esto sucede, k es una versión o un número de secuencia que identifica el evento particular, y v es un valor que representa la carga útil del evento (por ejemplo, todos los argumentos pasados en una llamada a un método). [1] [5] Cada flujo distribuido es un conjunto (posiblemente infinito) de cuádruples que satisfacen las siguientes tres propiedades formales.
Para cualquier punto finito en el tiempo t , sólo puede haber un número finito de eventos en el flujo que ocurran en el momento t o antes. Esto implica que en qué flujo siempre se puede señalar el punto en el tiempo en el que se originó el flujo. El flujo mismo puede ser infinito; en tal caso, en cualquier momento, eventualmente aparecerá un nuevo evento en el flujo.
Para cualquier par de eventos e_1 y e_2 que ocurran en la misma ubicación, si e_1 ocurre antes que e_2, entonces el número de versión en e_1 también debe ser menor que el de e_2.
Para cualquier par de eventos e_1 y e_2 que ocurran en la misma ubicación, si los dos eventos tienen los mismos números de versión, también deben tener los mismos valores.
Además de lo anterior, los flujos pueden tener una serie de propiedades adicionales.
Consistencia . Se dice que un flujo distribuido es consistente si eventos con la misma versión siempre tienen el mismo valor, incluso si ocurren en lugares diferentes. Los flujos consistentes generalmente representan varios tipos de decisiones globales tomadas por el protocolo o la aplicación.
Monotonicidad . Se dice que un flujo distribuido es débilmente monótono si para cualquier par de eventos e_1 y e_2 que ocurren en la misma ubicación, si e_1 tiene una versión más pequeña que e_2, entonces e_1 debe tener un valor menor que e_2. Se dice que un flujo distribuido es fuertemente monótono (o simplemente monótono ) si esto es cierto incluso para pares de eventos e_1 y e_2 que ocurren en diferentes ubicaciones. Los flujos fuertemente monótonos son siempre consistentes. Por lo general, representan varios tipos de decisiones irreversibles. Los flujos débilmente monótonos pueden ser consistentes o no. [3] [4]
Referencias
^ ab Ostrowski, K., Birman, K., Dolev, D. y Sakoda, C. (2009). "Implementación de flujos de eventos confiables en sistemas grandes mediante flujos de datos distribuidos y delegación recursiva", 3.ª Conferencia internacional ACM sobre sistemas distribuidos basados en eventos (DEBS 2009) , Nashville, TN, EE. UU., 6 al 9 de julio de 2009, http://www .cs.cornell.edu/~krzys/krzys_debs2009.pdf Archivado el 6 de junio de 2011 en Wayback Machine.
^ Ostrowski, K., Birman, K. y Dolev, D. (2009). "Lenguaje de flujo de datos distribuido para protocolos multipartitos", 5º Taller ACM SIGOPS sobre lenguajes de programación y sistemas operativos (PLOS 2009) , Big Sky, MT, EE. UU. 11 de octubre de 2009, http://www.cs.cornell.edu/~krzys/krzys_plos2009.pdf Archivado el 6 de junio de 2011 en Wayback Machine.
^ abc Ostrowski, K., Birman, K., Dolev, D. (2009). "Programación de objetos distribuidos en vivo con flujos de datos distribuidos", presentado a la Conferencia internacional sobre programación, sistemas, lenguajes y aplicaciones orientados a objetos (OOPSLA 2009) , http://www.cs.cornell.edu/~krzys/krzys_oopsla2009.pdf Archivado 2009-08-16 en la Wayback Machine.
^ abc De Francesco, N.; Perego, G.; Vaglini, G.; Vanneschi, M. (1 de diciembre de 1980). "Un marco para el procesamiento distribuido de flujo de datos". CALCÓL . 17 (4): 333–363. doi :10.1007/BF02578622. ISSN 1126-5434.
^ abc Reif, John H.; Smolka, Scott A. (febrero de 1990). "Análisis de flujo de datos de procesos de comunicación distribuida" (PDF) . Revista Internacional de Programación Paralela . 19 (1).
^ Gallizzi, Edmundo; Zondervan, Quinton (1992). "Sistema informático de flujo de datos distribuidos". ACM-SE 30: Actas de la 30ª conferencia regional anual del Sudeste . Prensa ACM: 421. doi :10.1145/503720.503770. ISBN978-0-89791-506-9.
