Los flujos de datos distribuidos tienen un propósito análogo al de las variables o parámetros de métodos en lenguajes de programación como Java , ya que pueden representar un 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 , no bloqueante y unidireccional . Cada evento representa una única instancia de una invocación de método asincrónica, unidireccional y no bloqueante u otra forma de paso de mensajes explícitos o implícitos entre dos capas o componentes de software. Por ejemplo, cada evento puede representar una única solicitud de 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 en el flujo distribuido sirven al mismo propósito funcional y lógico, y están relacionados entre sí; generalmente, requerimos que representen llamadas de método 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 de computadoras . 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 llevar 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 representan solicitudes de multidifusión, así como reconocimientos y notificaciones de error. [4] [6]
Concurrente , continuo y distribuido . El flujo suele incluir 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. Por lo tanto, 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 de este tipo realizadas por instancias de la aplicación dada 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 el que esto sucede, k es una versión o un número de secuencia que identifica el evento en particular, y v es un valor que representa la carga útil del evento (por ejemplo, todos los argumentos pasados en una llamada de método). [1] [5] Cada flujo distribuido es un conjunto (posiblemente infinito) de dichos cuádruples que satisface las siguientes tres propiedades formales.
Para cualquier punto finito en el tiempo t , solo puede haber un número finito de eventos en el flujo que ocurran en el tiempo t o antes. Esto implica que, en cualquier flujo, siempre se puede señalar el punto en el tiempo en el que se originó. El flujo en sí puede ser infinito; en tal caso, en cualquier punto en el tiempo, eventualmente aparecerá un nuevo evento en el flujo.
Para cualquier par de eventos e_1 y e_2 que ocurren en la misma ubicación, si e_1 ocurre en un momento anterior a 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.
Coherencia . Se dice que un flujo distribuido es coherente si los eventos con la misma versión siempre tienen el mismo valor, incluso si ocurren en diferentes ubicaciones. Los flujos coherentes suelen representar varios tipos de decisiones globales tomadas por el protocolo o la aplicación.
Monotonía . 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 más pequeño 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 a través de flujos de datos distribuidos y delegación recursiva", 3.ª Conferencia internacional de la ACM sobre sistemas distribuidos basados en eventos (DEBS 2009) , Nashville, TN, EE. UU., del 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). "Distributed Data Flow Language for Multi-Party Protocols", 5th ACM SIGOPS Workshop on Programming Languages and Operating Systems (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", enviado a la Conferencia internacional sobre programación orientada a objetos, sistemas, lenguajes y aplicaciones (OOPSLA 2009) , http://www.cs.cornell.edu/~krzys/krzys_oopsla2009.pdf Archivado el 16 de agosto de 2009 en 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". Calcolo . 17 (4): 333–363. doi :10.1007/BF02578622. ISSN 1126-5434.
^ abc Reif, John H.; Smolka, Scott A. (febrero de 1990). "Análisis del flujo de datos de procesos de comunicación distribuidos" (PDF) . Revista internacional de programación paralela . 19 (1): 1–30. doi :10.1007/BF01407862.
^ Gallizzi, Edmund; Zondervan, Quinton (1992). "Sistema de computación de flujo de datos distribuidos". Actas de la 30.ª conferencia regional anual del sudeste sobre - ACM-SE 30 . ACM Press. p. 421. doi :10.1145/503720.503770. ISBN978-0-89791-506-9.
