Inicio

Bienvenidos y bienvenidas a la cátedra de Técnicas de Programación Concurrente I de la Facultad de Ingeniería - UBA.

Los docentes de la Cátedra son:

Profesor: Ing. Pablo A. Deymonnaz
Jefe de Trabajos Practicos:
- Ing. Ariel Scarpinelli
Colaboradores:
- Nicolás Longo
Asesores:
- Dr. Mariano Méndez (asesor académico)
- Federico Carrone (asesor de la industria)
- Facundo Olano (asesor de la industria)

Las clases se desarrollan los días martes y miércoles de 19 a 22 hs a través de la plataforma Google Meet, se graban las clases.

Los enlaces para acceder a Meet, así como las grabaciones de clases anteriores, son de acceso exclusivo a los inscriptos a la materia.

Cronograma 2do cuatrimestre 2024

Fecha	Evento
28 de Agosto	TP1 - Presentación de enunciado
4 de Septiembre	No hay clases - Elecciones
18 de Septiembre	TP1 - Entrega
9 de Octubre	TP2 - Presentación de enunciado
16 de Octubre	Parcial
6 de Noviembre	Recuperatorio de parcial
13 de Noviembre	TP2 - Pre-entrega.
3 de Diciembre	TP2 - Entrega Final
3, 4, 10 y 11 de Diciembre	TP2 - Presentaciones
11 de Diciembre	2do recuperatorio de parcial

Clases

Semana	Teorica	Práctica
1	Introducción a Concurrencia	Introducción a Rust
2	Modelo Fork Join	Práctica sobre Fork Join
3	Programación Asincrónica	Práctica sobre Programación Asincrónica Vectorización
4	Corrección / Sección Crítica / Locks	Práctica sobre Locks
5	Sincronización / Semáforos y Barreras Monitores	Práctica sobre Sincronizacion
6	Redes de Petri	Práctica sobre Redes de Petri
7	Pasaje de Mensajes / Canales Actores	Práctica Channels y Actores
8	Concurrencia Distribuida: Algoritmos de Exclusión Mutua - Repaso de Redes. Sockets en UNIX	Práctica sobre Sockets y Exclusión Mutua distribuida
9	Concurrencia Distribuida (parte 2): Algoritmos de Elección - Sockets en Rust	Práctica de Algoritmos de Elección
10	Concurrencia Distribuida (parte 3): Transacciones - Deadlocks	Práctica de Transacciones Distribuidas
11	Ambientes Distribuidos	Práctica de Transacciones Distribuidas
Especiales	Lenguajes para concurrencia	Taller de Testing

2do Cuatrimestre 2024

Trabajo Práctico

Fecha de Entrega: 18 de Septiembre

PUBG es un juego de disparos en primera y tercera persona estilo Battle Royale que enfrenta a más de 90 jugadores en una gran isla donde los equipos y los jugadores luchan a muerte hasta que queda uno.

El sitio pubg.op.gg publica estadísticas sobre este juego.

Queremos analizar un dataset con dumps de este sitio para mejorar las estrategias de juego.

Objetivo

Implementar una aplicación en Rust para procesamiento de información, aprovechando las ventajas del modelo Fork-Join, utilizando el dataset https://www.kaggle.com/datasets/skihikingkevin/pubg-match-deaths

La información a obtener del mismo incluye:

El top 10 de armas (campo killed_by) que produjeron la mayor cantidad de muertes. En caso de empate, resolver alfabeticamente.
- De cada arma, el % del total de muertes que produjo, redondeado a dos decimales.
- El promedio de distancia entre el asesino y la víctima para esa arma (((killer_position_x - victim_position_x).powi(2) + (killer_position_y - victim_position_y).powi(2)).sqrt(); , redondeado a dos decimales.
EL top 10 de jugadores (campo killer_name) que produjeron la mayor cantidad de muertes. En caso de empate, resolver alfabeticamente.
- De cada jugador, el total de muertes que produjo.
- El top 3 de armas mas utilizadas por el jugador, junto con su % de uso respecto del total de muertes ocasionadas por ese jugador, redondeado a dos decimales. En caso de empate, resolver alfabeticamente.

Requerimientos

La aplicación debe recibir como parámetro de linea de comandos el path a un directorio, y debe procesar todos los archivos .csv en el mismo. Los archivos a procesar corresponden con el formato del directorio deaths dentro del dataset.
Debe recibir un segundo parámetro entero por linea de comandos indicando la cantidad de worker threads con la cual procesar la información
Debe recibir un tercer parámetro con el nombre del archivo de salida como resultado del procesamiento.

En resumen, la aplicación será ejecutada como cargo run <input-path> <num-threads> <output-file-name>

El formato del archivo de salida debe ser

{
    "padron": <número de padron del alumno>,
    "top_killers": {
        "<killer_name 1>": {
            "deaths": <cantidad total de muertes ejecutadas por el jugador>,
            "weapons_percentage": {
                "<weapon name 1>": <% de uso respecto del total de muertes ocasionadas por ese jugador>,
                ...
            }
        },
        ...
        "<killer_name N>" : {
            ...
        }
    },
    "top_weapons": {
        "<killed_by 1>": {
          "deaths_percentage": <% del total de muertes que produjo el arma>,
          "average_distance": <promedio de distancia entre el asesino y la víctima para el arma>
        },
        ...
        "<killed_by N>": {

        },
    }
}

Requerimientos no funcionales

Los siguientes son los requerimientos no funcionales para la resolución de los ejercicios:

El proyecto deberá ser desarrollado en lenguaje Rust, usando las herramientas de la biblioteca estándar.
El archivo Cargo.toml se debe encontrar en la raíz del repositorio, para poder ejecutar correctamente los tests automatizados
Se deberán utilizar las herramientas de concurrencia correspondientes al modelo forkjoin
No se permite utilizar crates externos, salvo los explícitamente mencionados en este enunciado, en los ejemplos de la materia, o autorizados expresamente por los profesores. Para el procesamiento de JSON se puede utilizar el crate serde_json.
El código fuente debe compilarse en la última versión stable del compilador y no se permite utilizar bloques unsafe.
El código deberá funcionar en ambiente Unix / Linux.
El programa deberá ejecutarse en la línea de comandos.
La compilación no debe arrojar warnings del compilador, ni del linter clippy.
Las funciones y los tipos de datos (struct) deben estar documentadas siguiendo el estándar de cargo doc.
El código debe formatearse utilizando cargo fmt.
Cada tipo de dato implementado debe ser colocado en una unidad de compilación (archivo fuente) independiente.

Entrega

La resolución del presente proyecto es individual.

La entrega del proyecto se realizará mediante Github Classroom. Cada estudiante tendrá un repositorio disponible para hacer diferentes commits con el objetivo de resolver el problema propuesto. Se recomienda iniciar tempranamente y hacer commits pequeños agreguen funcionalidad incrementalmente. Se podrán hacer commit hasta el día de la entrega a las 19 hs Arg, luego el sistema automáticamente quitará el acceso de escritura.

Evaluación

Principios teóricos y corrección de bugs

La evaluación se realizará sobre Github, pudiendo el profesor hacer comentarios en el repositorio y solicitar cambios o mejoras cuando lo encuentre oportuno, especialmente debido al uso incorrecto de herramientas de concurrencia.

Casos de prueba

Se someterá a la aplicación a diferentes casos de prueba que validen la correcta aplicación de las herramientas de concurrencia, por ejemplo, la ausencia de deadlocks.

Además la aplicación deberá respetar los formatos de salida y valores esperados de los resultados, y deberá mostrar algún incremento en performance cuando la ejecución de la misma se hace con varios hilos en un ambiente multiprocesador.

Organización del código

El código debe organizarse respetando los criterios de buen diseño y en particular aprovechando las herramientas recomendadas por Rust. Se prohibe el uso de bloques unsafe.

Tests automatizados

La presencia de tests automatizados que prueben diferentes casos, en especial sobre el uso de las herramientas de concurrencia es un plus.

Presentación en término

El trabajo deberá entregarse para la fecha estipulada. La presentación fuera de término sin coordinación con antelación con el profesor influye negativamente en la nota final.

Trabajo Práctico

Introducción

ConcuRide es una nueva aplicación para conectar conductores y pasajeros. Gracias a su inovadora implementación distribuida, permitirá reducir los costos y apuntar a ser líder en el mercado.

Los pasajeros tendrán una app donde podrán elegir el destino, y los choferes una app donde recibirán y podrán aceptar o denegar viajes.

Objetivo

Deberán implementar un conjunto de aplicaciones en Rust que modele el sistema.

Requerimientos

Una aplicación modelará la app para los pasajeros. Por simplificación, las coordenadas de origen y destino del viaje se modelarán con un par de enteros pequeños. Por ejemplo un viaje puede ser desde (3, 5) hacia (24,16). La app informará cuando un conductor acepte el viaje, y luego cuando esté terminado. Habrán varias instancias que se ejecutarán concurrentemente, una por cada pasajero.
Otra aplicación simulará a los conductores. Los mismos irán informando la ubicación actual del vehículo (simulada aleatoreamente o bien con un control, lo que simplifique los casos de prueba). El conductor recibirá ofertas de viajes cercanos a su posición actual (por ejemplo con una distancia de 5 entre el origen y su posición). Un único conductor puede recibir la oferta del viaje por cada vez; y tiene un tiempo corto para aceptarla. La aceptación o rechazo se modelará con un random. Al aceptar, el tiempo viaje se modelará con un sleep, luego del cual se terminará el viaje y el conductor quedará disponible para tomar otro.
Se debe considerar la autorización del pago al momento de solicitar el viaje, y el cobro efectivo al momento de llegar a destino. Modelar el gateway de pagos con una aplicación simple que loguea. Considerar que al momento de autorizar el pago, el gateway puede rechazar la tarjeta aleatoriamente con una probabilidad.
El sistema debe ser resiliente, soportando la caida de algunas instancias de las aplicaciones.
El sistema debe intentar minimizar la cantidad de mensajes que viajan por toda la red; por ejemplo enviando mensajes solo a los nodos que se encuentren cercanos por ubicación.

Requerimientos no funcionales

Los siguientes son los requerimientos no funcionales para la resolución de los ejercicios:

El proyecto deberá ser desarrollado en lenguaje Rust, usando las herramientas de la biblioteca estándar.
Por lo menos alguna, si no todas las aplicaciones implementadas deben funcionar utilizando el modelo de actores.
Cada instancia de cada aplicación debe ejecutarse en un proceso independiente.
En el modelado de la solución se deberán utilizar una o mas de las herramientas de concurrencia distribuida mostradas en la cátedra. Por ejemplo exclusiones mutuas distribuidas, elección de líder, algorítmos de anillo, commits de dos fases, etc.
No se permite utilizar crates externos, salvo los explícitamente mencionados en este enunciado, los utilizados en las clases, o los autorizados expresamente por los profesores.
El código fuente debe compilarse en la última versión stable del compilador y no se permite utilizar bloques unsafe.
El código deberá funcionar en ambiente Unix / Linux.
El programa deberá ejecutarse en la línea de comandos.
La compilación no debe arrojar warnings del compilador, ni del linter clippy.
Las funciones y los tipos de datos (struct) deben estar documentadas siguiendo el estándar de cargo doc.
El código debe formatearse utilizando cargo fmt.
Cada tipo de dato implementado debe ser colocado en una unidad de compilación (archivo fuente) independiente.

Entregas

La resolución del presente proyecto es en grupos de tres integrantes.

Las entregas del proyecto se realizarán mediante Github Classroom. Cada grupo tendrá un repositorio disponible para hacer diferentes commits con el objetivo de resolver el problema propuesto.

Primera entrega: Diseño

Deberán entregar un informe en formato Markdown en el README.md del repositorio que contenga una explicación del diseño y de las decisiones tomadas para la implementación de la solución, asi como diagramas de threads y procesos, y la comunicación entre los mismos; y diagramas de las entidades principales.

De cada entidad se debe describir:

Finalidad general
Su estado interno, como uno o varios structs en pseudocodigo de Rust.
Mensajes que recibe, struct del payload de los mismos y como reaccionará cuando los recibe.
Mensajes que envía, struct del payload de los mismos y hacia quienes son enviados.
Protolos de transporte (TCP/UDP) y de aplicación que utiliza para comunicarse.
Casos de interés (felices, caídas)

Se recomienda fuertemente que las implementaciones de las ideas de diseño se encuentren realizadas mínimamente, para validar el mismo.

Fecha máxima de Entrega: 13 de Noviembre de 2024

Presentar como un pull-request del README.md.

El diseño será evaluado por la cátedra y de no presentarse a término el trabajo quedará automaticamente desaprobado.

La cátedra podrá solicitar correciones que deberán realizarse en el mismo diseño, y puntos de mejora que deberán tenerse en cuenta durante la implementación.

Se podrán hacer commits hasta el día de la entrega a las 19 hs Arg, luego el sistema automáticamente quitará el acceso de escritura.

Segunda entrega: Código final - 3 de Diciembre de 2024

Deberá incluirse el código de la solución completa.
Deberá actualizarse el readme, con una sección dedicada a cambios que se hayan realizado desde la primera entrega. Además debe incluir cualquier explicación y/o set de comandos necesarios para la ejecución de los programas.

Presentación final: 3, 4, 10 y 11 de Diciembre

Cada grupo presentará presencialmente a un profesor de la cátedra su trabajo. La fecha y horario para cada grupo serán definidos oportunamente.

La presentación deberá incluir un resumen del diseño de la solución y la muestra en vivo de las aplicaciones funcionando, demostrando casos de interes.

Todos los integrantes del grupo deberán exponer algo. La evaluación es individual.

La cátedra podrá solicitar luego correcciones donde se encuentren errores severos, sobre todo en el uso de herramientas de concurrencia; o bien desviaciones respecto al diseño pactado inicialmente.

De tener correciones para realizar, las mismas deben realizarse y aprobarse con anterioridad a la presentación a examen final.

Evaluación

Principios teóricos y corrección de bugs

Los alumnos presentarán el diseño, código y comportamiento en vivo de su solución, con foco en el uso de las diferentes herramientas de concurrencia.

Deberán poder explicar desde los conceptos teóricos vistos en clase cómo se comportará potencialmente su solución ante problemas de concurrencia (por ejemplo ausencia de deadlocks).

En caso de que la solución no se comportara de forma esperada, deberán poder explicar las causas y sus posibles rectificaciones.

Casos de prueba

Se someterá a la aplicación a diferentes casos de prueba que validen la correcta aplicación de las herramientas de concurrencia y la resiliencia de las distintas entidades.

Informe

El informe debe poder dar cuenta de todas las decisiones tomadas para implementar la solución, incluyendo diferentes diagramas y se debe poder utilizar como soporte para que el equipo presente su trabajo.

Organización del código

El código debe organizarse respetando los criterios de buen diseño y en particular aprovechando las herramientas recomendadas por Rust. Se prohibe el uso de bloques unsafe.

Tests automatizados

La entrega debe contar con tests automatizados que prueben diferentes casos. Se considerará en especial aquellos que pongan a prueba el uso de las herramientas de concurrencia.

Presentación en término

El trabajo deberá entregarse para la fecha estipulada. La presentación fuera de término sin coordinación con antelación con el profesor influirá negativamente en la nota final.

1er Cuatrimestre 2024

Trabajo Práctico

Fecha de Entrega: 17 de Abril

Introducción

Stack Exchange publica periódicamente el dump de todas las preguntas y respuestas realizadas en los sitios de su red.

Queremos aprovechar esto para realizar un análisis de los temas que se hablan en los sitios. Para ello utilizaremos los tags que cada pregunta tiene asociada.

Objetivo

Implementar una aplicación en Rust para procesamiento de información, aprovechando las ventajas del modelo Fork-Join, utilizando el dataset https://huggingface.co/datasets/flax-sentence-embeddings/stackexchange_title_body_jsonl

Requerimientos

La aplicación debe procesar todos los archivos .jsonl en el subdirectorio data. Puede utilizar el comando download_data.sh para descargar el dataset y descomprimirlo automáticamente.
Debe recibir un único parámetro entero por linea de comandos indicando la cantidad de worker threads con la cual procesar la información
Debe presentar un resultado final de procesamiento en JSON por consola con el siguiente formato

{
    "padron": <número de padron del alumno>,
    "sites": {
        "site1": {
            "questions": <cantidad total de preguntas para ese sitio>,
            "words": <cantidad total de palabras para ese sitio>,
            "tags": {
                "tag1": {
                    "questions": <cantidad total de preguntas para ese tag para ese sitio>,
                    "words": <cantidad total palabras para ese tag para ese sitio>,
                },
                ...
                "tagN": {

                },
            }
            "chatty_tags": [
                "tag1", "tag2", ... // los 10 tags con mayor relación words/questions para ese sitio
            ]
        },
        ...
        "siteN" : {
            ...
        }
    },
    "tags": {
        "tag1": {
            "questions": <cantidad total de preguntas para ese tag para todos los sitios>,
            "words": <cantidad total palabras para ese tag para todos los sitios>,
        },
        ...
        "tagN": {

        },
    },
    "totals": {
        "chatty_sites": [
            "site1", "site2", ... // los 10 sitios con mayor relación words/questions
        ],
        "chatty_tags": [
            "tag1", "tag2", ... // los 10 tags con mayor relación words/questions entre todos los sitios.
        ]
    }
}

Requerimientos no funcionales

Los siguientes son los requerimientos no funcionales para la resolución de los ejercicios:

El proyecto deberá ser desarrollado en lenguaje Rust, usando las herramientas de la biblioteca estándar.
El archivo Cargo.toml se debe encontrar en la raíz del repositorio, para poder ejecutar correctamente los tests automatizados
Se deberán utilizar las herramientas de concurrencia correspondientes al modelo forkjoin
No se permite utilizar crates externos, salvo los explícitamente mencionados en este enunciado, en los ejemplos de la materia, o autorizados expresamente por los profesores. Para el procesamiento de JSON se puede utilizar el crate serde_json.
El código fuente debe compilarse en la última versión stable del compilador y no se permite utilizar bloques unsafe.
El código deberá funcionar en ambiente Unix / Linux.
El programa deberá ejecutarse en la línea de comandos.
La compilación no debe arrojar warnings del compilador, ni del linter clippy.
Las funciones y los tipos de datos (struct) deben estar documentadas siguiendo el estándar de cargo doc.
El código debe formatearse utilizando cargo fmt.
Cada tipo de dato implementado debe ser colocado en una unidad de compilación (archivo fuente) independiente.

Entrega

La resolución del presente proyecto es individual.

Evaluación

Principios teóricos y corrección de bugs

Casos de prueba

Se someterá a la aplicación a diferentes casos de prueba que validen la correcta aplicación de las herramientas de concurrencia.

Organización del código

El código debe organizarse respetando los criterios de buen diseño y en particular aprovechando las herramientas recomendadas por Rust. Se prohibe el uso de bloques unsafe.

Tests automatizados

La presencia de tests automatizados que prueben diferentes casos, en especial sobre el uso de las herramientas de concurrencia es un plus.

Presentación en término

El trabajo deberá entregarse para la fecha estipulada. La presentación fuera de término sin coordinación con antelación con el profesor influye negativamente en la nota final.

Trabajo Práctico

Introducción

Una importante cadena de heladerías desea abrir una sucursal completamente robotizada. Los clientes harán su pedido sobre una interfáz gráfica eligiendo gustos y tamaño. Luego un conjunto de robots podrán resolver los pedidos de forma concurrente, tal como lo hacen los heladeros los días de calor. Así mismo, cada contenedor con un gusto de helado podrá ser utilizado solamente por un robot a la vez. Finalmente se le entregará su helado al cliente; y solamente se le cobrará en la tarjeta si efectivamente se pudo completar su pedido.

Objetivo

Deberán implementar un conjunto de aplicaciones en Rust que modele el sistema de la heladería.

Requerimientos

Una aplicación modelará las interfaces con los clientes, las cuales generarán ordenes de pedido según un archivo de pedidos simulado. Deben soportar varios gustos y tamaños posibles de contenedor. Habrán varias instancias, tantas como pantallas disponibles en el local.
Otra aplicación simulará los robots, los cuales tomarán un pedido y deberán obtener los ingredientes necesarios para llenar el contenedor. El tamaño del contenedor definirá el tiempo para simular cada pedido. Nuevamente, serán varios los robots que despachen pedidos.
De alguna forma el sistema deberá modelar los contendores con gustos y el stock disponible en cada uno. Eventualmente algun gusto quedará sin stock, y un robot que necesite ese gusto deberá cancelar el pedido.
Se debe considerar la captura del pago al momento de realizar el pedido, y el cobro efectivo al momento de entrega, o bien su cancelación. Modelar el gateway de pagos con una aplicación simple que loguea. Considerar que al momento de capturar el pago, el gateway puede rechazar la tarjeta aleatoriamente con una probabilidad.
El sistema debe ser resiliente, soportando la caida de algunas instancias de las aplicaciones.

Requerimientos no funcionales

Los siguientes son los requerimientos no funcionales para la resolución de los ejercicios:

El proyecto deberá ser desarrollado en lenguaje Rust, usando las herramientas de la biblioteca estándar.
Por lo menos alguna, si no todas las aplicaciones implementadas deben funcionar utilizando el modelo de actores.
En el modelado de la solución se deberán utilizar una o mas de las herramientas de concurrencia distribuida mostradas en la cátedra. Por ejemplo exclusiones mutuas distribuidas, elección de líder, algorítmos de anillo, commits de dos fases, etc.
No se permite utilizar crates externos, salvo los explícitamente mencionados en este enunciado, los utilizados en las clases, o los autorizados expresamente por los profesores.
El código fuente debe compilarse en la última versión stable del compilador y no se permite utilizar bloques unsafe.
El código deberá funcionar en ambiente Unix / Linux.
El programa deberá ejecutarse en la línea de comandos.
La compilación no debe arrojar warnings del compilador, ni del linter clippy.
Las funciones y los tipos de datos (struct) deben estar documentadas siguiendo el estándar de cargo doc.
El código debe formatearse utilizando cargo fmt.
Cada tipo de dato implementado debe ser colocado en una unidad de compilación (archivo fuente) independiente.

Entregas

La resolución del presente proyecto es en grupos de tres integrantes.

Las entregas del proyecto se realizarán mediante Github Classroom. Cada grupo tendrá un repositorio disponible para hacer diferentes commits con el objetivo de resolver el problema propuesto.

Primera entrega: Diseño

Se recomienda fuertemente que las implementaciones de las ideas de diseño se encuentren realizadas mínimamente, para validar el mismo.

Fecha máxima de Entrega: 12 de Junio de 2024

El diseño será evaluado por la cátedra y de no presentarse a término el trabajo quedará automaticamente desaprobado.

La cátedra podrá solicitar correciones que deberán realizarse en el mismo diseño, y puntos de mejora que deberán tenerse en cuenta durante la implementación.

Se podrán hacer commits hasta el día de la entrega a las 19 hs Arg, luego el sistema automáticamente quitará el acceso de escritura.

Segunda entrega:** 26 de Junio de 2024

Deberá incluirse el código de la solución completa.
Deberá actualizarse el readme, con una sección dedicada a cambios que se hayan realizado desde la primera entrega. Además debe incluir cualquier explicación y/o set de comandos necesarios para la ejecución de los programas.
Debera incluir un enlace a un video de no más de 7 minutos donde cada integrante presente su participación principal en el proyecto, explicando las partes más relevantes del código que trabajó. El video debe mostrar además la solución funcionando en diferentes casos de interés.

De tener correciones para realizar, las mismas deben realizarse y aprobarse con anterioridad a la presentación a examen final.

Entrega final

Durante el examen final, los alumnos deberán poder responder preguntas sobre su diseño e implementación, y su participación personal en el trabajo; además de las preguntas y situaciones problemáticas propias de los contenidos presentados por la cátedra durante toda la materia.

Evaluación

Principios teóricos y corrección de bugs

Los alumnos presentarán el código de su solución primero en video, y luego personalmente, con foco en el uso de las diferentes herramientas de concurrencia. Deberán poder explicar desde los conceptos teóricos vistos en clase cómo se comportará potencialmente su solución ante problemas de concurrencia (por ejemplo ausencia de deadlocks).

En caso de que la solución no se comportara de forma esperada, deberán poder explicar las causas y sus posibles rectificaciones.

Casos de prueba

Se someterá a la aplicación a diferentes casos de prueba que validen la correcta aplicación de las herramientas de concurrencia y la resiliencia de las distintas entidades.

Informe

Organización del código

El código debe organizarse respetando los criterios de buen diseño y en particular aprovechando las herramientas recomendadas por Rust. Se prohibe el uso de bloques unsafe.

Tests automatizados

La entrega debe contar con tests automatizados que prueben diferentes casos. Se considerará en especial aquellos que pongan a prueba el uso de las herramientas de concurrencia.

Presentación en término

El trabajo deberá entregarse para la fecha estipulada. La presentación fuera de término sin coordinación con antelación con el profesor influirá negativamente en la nota final.

2do Cuatrimestre 2023

Trabajo Práctico

Fecha de Entrega: 21 de Noviembre de 2023

Introducción

Nos encontramos desarrollando un software para una cadena de tiendas distribuida por todo el país. La misma tiene un sitio de e-commerce además de locales físicos.

En este caso estamos trabajando el módulo de manejo de stocks. Se pueden registrar compras en cada tienda física, así como también desde el e-commerce. El sitio de e-commerce reserva stock de producto de la tienda más cercana posible a la dirección de envío de la compra idealmente (modelar de forma aleatoria), pero puede potencialmente tomar el stock de cualquier local de ser necesario.

Objetivo

Deberán implementar un conjunto de aplicaciones en Rust que modele el sistema de stocks.

Requerimientos

Una aplicación modelará el sitio de e-commerce, la cual generará ordenes según un archivo de pedidos simulado.
Otra aplicación simulará las terminales de cobro en los locales, habiendo N instancias de esta aplicación (una por cada local). Cada terminal simulará los pedidos también desde un archivo de ordenes.
En el caso de compras por e-commerce, el stock del producto se bloquea, pero no se descuenta hasta que el producto es efectivamente entregado.
La entrega puede no realizarse a tiempo, con lo cual la compra se cancela y el stock se libera (modelar con un random).
Debido a que las tiendas se encuentran por todo el pais, en algunos casos con muy mala conexión, los nodos de cada tienda pueden entrar y salir de la red espontáneamente.
Mientras se encuentran fuera de red, los servidores pueden seguir actualizando stocks con ventas locales; no así con las de e-commerce.
Al volver a conectarse, deben sincronizar los stocks

Requerimientos no funcionales

Los siguientes son los requerimientos no funcionales para la resolución de los ejercicios:

El proyecto deberá ser desarrollado en lenguaje Rust, usando las herramientas de la biblioteca estándar.
Alguna de las aplicaciones implementadas debe funcionar utilizando el modelo de actores.
No se permite utilizar crates externos, salvo los explícitamente mencionados en este enunciado, o autorizados expresamente por los profesores.
El código fuente debe compilarse en la última versión stable del compilador y no se permite utilizar bloques unsafe.
El código deberá funcionar en ambiente Unix / Linux.
El programa deberá ejecutarse en la línea de comandos.
La compilación no debe arrojar warnings del compilador, ni del linter clippy.
Las funciones y los tipos de datos (struct) deben estar documentadas siguiendo el estándar de cargo doc.
El código debe formatearse utilizando cargo fmt.
Cada tipo de dato implementado debe ser colocado en una unidad de compilación (archivo fuente) independiente.

Entrega

La resolución del presente proyecto es en grupos de tres integrantes.

La entrega del proyecto se realizará mediante Github Classroom. Cada grupo tendrá un repositorio disponible para hacer diferentes commits con el objetivo de resolver el problema propuesto. Se recomienda iniciar tempranamente y trabajar siguiendo un formato de commits pequeños que agreguen funcionalidad incrementalmente. Se podrán hacer commits hasta el día de la entrega a las 19 hs Arg, luego el sistema automáticamente quitará el acceso de escritura.

Asi mismo el proyecto debe incluir un informe en formato Markdown en el README.md del repositorio que contenga una explicación del diseño y de las decisiones tomadas para la implementación de la solución, asi como diagramas de threads y procesos, y la comunicación entre los mismos; y diagramas de las entidades principales. En el mismo archivo deberá proveerse cualquier explicación y/o set de comandos necesarios para la ejecución de los programas.

Evaluación

Principios teóricos y corrección de bugs

Los alumnos presentarán el código de su solución presencialmente, con foco en el uso de las diferentes herramientas de concurrencia. Deberán poder explicar desde los conceptos teóricos vistos en clase cómo se comportará potencialmente su solución ante problemas de concurrencia (por ejemplo ausencia de deadlocks).

En caso de que la solución no se comportara de forma esperada, deberán poder explicar las causas y sus posibles rectificaciones.

Casos de prueba

Se someterá a la aplicación a diferentes casos de prueba que validen la correcta aplicación de las herramientas de concurrencia.

Informe

Organización del código

El código debe organizarse respetando los criterios de buen diseño y en particular aprovechando las herramientas recomendadas por Rust. Se prohibe el uso de bloques unsafe.

Tests automatizados

La entrega debe contar con tests automatizados que prueben diferentes casos. Se considerará en especial aquellos que pongan a prueba el uso de las herramientas de concurrencia.

Presentación en término

El trabajo deberá entregarse para la fecha estipulada. La presentación fuera de término sin coordinación con antelación con el profesor influirá negativamente en la nota final.

1er Cuatrimestre 2023

Trabajo Práctico

Fecha de Entrega: 3 de mayo de 2023

Introducción

CoffeeGPT es una nueva cadena de cafeterías que pretende competir con tantas otras con un novedoso modelo de negocio: los clientes son servidos por robots que preparan sus órdenes de forma totalmente automática.

De entre los multiples desarrollos necesarios para implementar este proyecto, nos han contratado para realizar el software que controlará las cafeteras espresso.

Objetivo

Deberán implementar una aplicación en Rust que modele el sistema de control y reporte de la cafetera inteligente.

Cada pedido de bebida a preparar se leerá como una línea de un archivo y los movimientos de los distintos actuadores se simularán con un sleep.

Requerimientos

Cada cafetera dispone de N dispensadores independientes que pueden aplicar agua caliente, café molido, cacao o espuma de leche.
Además la cafetera esta compuesta por:
- Un contenedor de granos para moler de capacidad G
- Un contenedor para granos molidos de capacidad M
- Un contenedor de leche fría de capacidad L
- Un contenedor de espuma de leche de capacidad E
- Un contenedor de cacao de capacidad C
- Un contenedor de agua, donde esta se toma de la red y luego calienta, de capacidad A.
Cada pedido se representa con una línea en un archivo de texto que indicará las cantidades de café molido, agua caliente, cacao y/o espuma de leche necesarias para preparar la bebida solicitada.
Las cantidades se "aplicarán" como tiempos de sleep además de descontar del correspondiente contenedor.
Un solo dispenser a por vez puede tomar ingredientes de cada contenedor, es decir, no es posible por ejemplo que dos disponsers tomen café concurrentemente.
Cuando el contenedor de cafe molido se agota, el molinillo automático toma una cantidad de granos y los convierte en café molido. Este proceso toma tiempo y no se puede obtener café durante el mismo.
Análogamente sucede lo mismo con la leche y la espuma, y con el agua caliente.
El sistema debe minimizar los tiempos de espera de los clientes, maximizando la producción concurrente.
El sistema debe alertar por consola cuando los contenedores de granos, leche y cacao se encuentran por debajo de X% de capacidad.
El sistema debe presentar periódicamente estadísticas con los niveles de todos los contenedores, cantidad total de bebidas preparadas y cantidad total de ingredientes consumidos.

Requerimientos no funcionales

Los siguientes son los requerimientos no funcionales para la resolución de los ejercicios:

El proyecto deberá ser desarrollado en lenguaje Rust, usando las herramientas de la biblioteca estándar.
Se deberán utilizar las herramientas de concurrencia correspondientes al modelo de estado mutable compartido.
No se permite utilizar crates externos, salvo los explícitamente mencionados en este enunciado, o autorizados expresamente por los profesores.
El código fuente debe compilarse en la última versión stable del compilador y no se permite utilizar bloques unsafe.
El código deberá funcionar en ambiente Unix / Linux.
El programa deberá ejecutarse en la línea de comandos.
La compilación no debe arrojar warnings del compilador, ni del linter clippy.
Las funciones y los tipos de datos (struct) deben estar documentadas siguiendo el estándar de cargo doc.
El código debe formatearse utilizando cargo fmt.
Cada tipo de dato implementado debe ser colocado en una unidad de compilación (archivo fuente) independiente.

Entrega

La resolución del presente proyecto es individual.

La entrega del proyecto se realizará mediante Github Classroom. Cada estudiante tendrá un repositorio disponible para ir haciendo diferentes commits con el objetivo de resolver el problema propuesto. Se recomienda iniciar tempranamente y hacer commits pequeños agreguen funcionalidad incrementalmente. Se podrán hacer commit hasta el día de la entrega a las 19 hs Arg, luego el sistema automáticamente quitará el acceso de escritura.

Asi mismo el proyecto debe incluir un pequeño informe en formato Markdown en el README.md del repositorio que contenga una explicación del diseño y de las decisiones tomadas para la implementación de la solución.

Evaluación

Principios teóricos y corrección de bugs

Casos de prueba

Se someterá a la aplicación a diferentes casos de prueba que validen la correcta aplicación de las herramientas de concurrencia.

Informe

El informe debe estar estructurado profesionalmente y debe poder dar cuenta de las decisiones tomadas para implementar la solución.

Organización del código

El código debe organizarse respetando los criterios de buen diseño y en particular aprovechando las herramientas recomendadas por Rust. Se prohibe el uso de bloques unsafe.

Tests automatizados

La presencia de tests automatizados que prueben diferentes casos, en especial sobre el uso de las herramientas de concurrencia es un plus.

Presentación en término

El trabajo deberá entregarse para la fecha estipulada. La presentación fuera de término sin coordinación con antelación con el profesor influye negativamente en la nota final.

Trabajo Práctico

Fecha de Entrega: 13 de junio de 2023

Introducción

Continuamos con los desarrollos para CoffeeGPT.

Coffeewards, es un sistema de puntos para fidelización de los clientes. Por cada compra que realizan los clientes, suman puntos que luego pueden canjear por cafes gratuitos.

Objetivo

Deberán implementar un conjunto de aplicaciones en Rust que modele el sistema de puntos.

Requerimientos

Una aplicación modelará la cafetera robot, la cual agregará o retirará puntos de las tarjetas, según un archivo de pedidos simulado. Deberán correr varias instancias en simultáneo, simulando los multiples locales de la empresa y cafeteras de cada local.
Cada cliente suma y comparte sus puntos con su grupo familiar; por lo tanto una misma cuenta de puntos se puede estar utilizando en varios locales/cafeteras en simultáneo. Se debe mantener el saldo de cada cuenta consistente.
En el caso de pagar un café con puntos, los mismos se bloquean, pero no se descuentan hasta que el café fue efectivamente entregado al cliente.
La cafetera puede fallar en preparar la bebida con cierta probabilidad, debiendo devolver los puntos.
El sistema es distribuido, cada local de CoffeeGPT tiene un servidor que mantiene los estados de cuenta. Las cafeteras se conectan con su servidor local.
Debido a que se encuentran por todo el pais, en algunos casos con muy mala conexión, los servidores pueden entrar y salir de la red espontáneamente.
- Mientras se encuentran fuera de red, los servidores pueden seguir acumulando puntos en las cuentas. No así retirar.
- Al volver a conectarse, deben sincronizar los estados de cuenta

Requerimientos no funcionales

Los siguientes son los requerimientos no funcionales para la resolución de los ejercicios:

El proyecto deberá ser desarrollado en lenguaje Rust, usando las herramientas de la biblioteca estándar.
Alguna de las aplicaciones implementadas debe funcionar utilizando el modelo de actores.
No se permite utilizar crates externos, salvo los explícitamente mencionados en este enunciado, o autorizados expresamente por los profesores.
El código fuente debe compilarse en la última versión stable del compilador y no se permite utilizar bloques unsafe.
El código deberá funcionar en ambiente Unix / Linux.
El programa deberá ejecutarse en la línea de comandos.
La compilación no debe arrojar warnings del compilador, ni del linter clippy.
Las funciones y los tipos de datos (struct) deben estar documentadas siguiendo el estándar de cargo doc.
El código debe formatearse utilizando cargo fmt.
Cada tipo de dato implementado debe ser colocado en una unidad de compilación (archivo fuente) independiente.

Entrega

La resolución del presente proyecto es en grupos de tres integrantes.

La entrega del proyecto se realizará mediante Github Classroom. Cada grupo tendrá un repositorio disponible para hacer diferentes commits con el objetivo de resolver el problema propuesto. Se recomienda iniciar tempranamente y hacer commits pequeños agreguen funcionalidad incrementalmente. Se podrán hacer commits hasta el día de la entrega a las 19 hs Arg, luego el sistema automáticamente quitará el acceso de escritura.

Asi mismo el proyecto debe incluir un informe en formato Markdown en el README.md del repositorio que contenga una explicación del diseño y de las decisiones tomadas para la implementación de la solución, asi como diagramas de threads y procesos, y la comunicación entre los mismos; y diagramas de las entidades principales.

Evaluación

Principios teóricos y corrección de bugs

En caso de que la solución no se comportara de forma esperada, deberán poder explicar las causas y sus posibles rectificaciones.

Casos de prueba

Se someterá a la aplicación a diferentes casos de prueba que validen la correcta aplicación de las herramientas de concurrencia.

Informe

El informe debe estar estructurado profesionalmente y debe poder dar cuenta de las decisiones tomadas para implementar la solución.

Organización del código

El código debe organizarse respetando los criterios de buen diseño y en particular aprovechando las herramientas recomendadas por Rust. Se prohibe el uso de bloques unsafe.

Tests automatizados

La presencia de tests automatizados que prueben diferentes casos, en especial sobre el uso de las herramientas de concurrencia es un plus.

Presentación en término

El trabajo deberá entregarse para la fecha estipulada. La presentación fuera de término sin coordinación con antelación con el profesor influye negativamente en la nota final.

2do Cuatrimestre 2022

Trabajo Práctico

Fecha de Entrega: 12 de octubre de 2022

Introducción

Internet of Coffee es una nueva cadena de cafeterías que pretende competir con tantas otras con un novedoso modelo de negocio: los clientes son servidos por robots que preparan sus órdenes de forma totalmente automática.

De entre los multiples desarrollos necesarios para implementar este proyecto, nos han contratado para realizar el software que controlará las cafeteras espresso.

Objetivo

Deberán implementar una aplicación en Rust que modele el sistema de control y reporte de la cafetera inteligente.

Cada pedido de bebida a preparar se leerá como una línea de un archivo y los movimientos de los distintos actuadores se simularán con un sleep.

Requerimientos

Cada cafetera dispone de N dispensadores independientes que pueden aplicar agua caliente, café o espuma de leche.
Además la cafetera esta compuesta por:
- Un contenedor de granos para moler de capacidad G
- Un contenedor para granos molidos de capacidad C
- Un contenedor de leche fría de capacidad L
- Un contenedor de espuma de leche de capacidad E
- Por simplificación el agua es ilimitada, ya que se toma de la red.
Cada pedido se representa con una línea en un archivo de texto. Por simplificación cada pedido "viene" con su correspondiente vaso el cual se posiciona de forma externa a nuestro sistema directamente en el dispensador correcto.
Cada pedido indicará las cantidades de cafe molido, agua caliente y/o espuma de leche necesarias.
Las cantidades se "aplicarán" como tiempos de sleep además de descontar del correspondiente contenedor.
Un solo dispenser a la vez puede tomar café molido o espuma de leche. El agua es libre.
Cuando el contenedor de cafe molido se agota, el molinillo automático toma una cantidad de granos y los convierte en café molido. Este proceso toma tiempo y no se puede obtener café durante el mismo.
Análogamente sucede lo mismo con la leche y la espuma.
El sistema debe minimizar los tiempos de espera de los clientes, maximizando la producción concurrente.
El sistema debe alertar por consola cuando los contenedores de granos y leche se encuentran por debajo de X% de capacidad.
El sistema debe presentar periódicamente estadísticas con los niveles de todos los contenedores, cantidad total de bebidas preparadas y cantidad total de ingredientes consumidos.

Requerimientos no funcionales

Los siguientes son los requerimientos no funcionales para la resolución de los ejercicios:

El proyecto deberá ser desarrollado en lenguaje Rust, usando las herramientas de la biblioteca estándar.
Se deberán utilizar las herramientas de concurrencia correspondientes al modelo de estado mutable compartido.
No se permite utilizar crates externos, salvo los explícitamente mencionados en este enunciado, o autorizados expresamente por los profesores.
El código fuente debe compilarse en la última versión stable del compilador y no se permite utilizar bloques unsafe.
El código deberá funcionar en ambiente Unix / Linux.
El programa deberá ejecutarse en la línea de comandos.
La compilación no debe arrojar warnings del compilador, ni del linter clippy.
Las funciones y los tipos de datos (struct) deben estar documentadas siguiendo el estándar de cargo doc.
El código debe formatearse utilizando cargo fmt.
Cada tipo de dato implementado debe ser colocado en una unidad de compilación (archivo fuente) independiente.

Entrega

La resolución del presente proyecto es individual.

Evaluación

Principios teóricos y corrección de bugs

Casos de prueba

Se someterá a la aplicación a diferentes casos de prueba que validen la correcta aplicación de las herramientas de concurrencia.

Informe

El informe debe estar estructurado profesionalmente y debe poder dar cuenta de las decisiones tomadas para implementar la solución.

Organización del código

El código debe organizarse respetando los criterios de buen diseño y en particular aprovechando las herramientas recomendadas por Rust. Se prohibe el uso de bloques unsafe.

Tests automatizados

La presencia de tests automatizados que prueben diferentes casos, en especial sobre el uso de las herramientas de concurrencia es un plus.

Presentación en término

El trabajo deberá entregarse para la fecha estipulada. La presentación fuera de término sin coordinación con antelación con el profesor influye negativamente en la nota final.

Trabajo Práctico

Fecha de Entrega: 22 de noviembre de 2022

Introducción

Continuamos con los desarrollos para Internet of Coffee.

Coffeewards, es un sistema de puntos para fidelización de los clientes. Por cada compra que realizan los clientes, suman puntos que luego pueden canjear por cafes gratuitos.

Objetivo

Deberán implementar un conjunto de aplicaciones en Rust que modele el sistema de puntos.

Requerimientos

Una aplicación modelará la cafetera robot, la cual agregará o retirará puntos de las tarjetas, según un archivo de pedidos simulado. Deberán correr varias instancias en simultáneo, simulando los multiples locales de la empresa y cafeteras de cada local.
Cada cliente suma y comparte sus puntos con su grupo familiar; por lo tanto una misma tarjeta de puntos se puede estar utilizando en varios locales/cafeteras en simultáneo. Se debe mantener el saldo de cada cuenta consistente.
En el caso de pagar un café con puntos, los mismos se bloquean, pero no se descuentan hasta que el café fue efectivamente entregado al cliente.
La cafetera puede fallar en preparar la bebida con cierta probabilidad, debiendo devolver los puntos.
El sistema es distribuido, cada local de Internet of Coffee tiene un servidor que mantiene los estados de cuenta. Las cafeteras se conectan con su servidor local.
Debido a que se encuentran por todo el pais, en algunos casos con muy mala conexión, los servidores pueden entrar y salir de la red espontáneamente.
- Mientras se encuentran fuera de red, los servidores pueden seguir acumulando puntos en las cuentas. No así retirar.
- Al volver a conectarse, deben sincronizar los estados de cuenta

Requerimientos no funcionales

Los siguientes son los requerimientos no funcionales para la resolución de los ejercicios:

El proyecto deberá ser desarrollado en lenguaje Rust, usando las herramientas de la biblioteca estándar.
Alguna de las aplicaciones implementadas debe funcionar utilizando el modelo de actores.
No se permite utilizar crates externos, salvo los explícitamente mencionados en este enunciado, o autorizados expresamente por los profesores.
El código fuente debe compilarse en la última versión stable del compilador y no se permite utilizar bloques unsafe.
El código deberá funcionar en ambiente Unix / Linux.
El programa deberá ejecutarse en la línea de comandos.
La compilación no debe arrojar warnings del compilador, ni del linter clippy.
Las funciones y los tipos de datos (struct) deben estar documentadas siguiendo el estándar de cargo doc.
El código debe formatearse utilizando cargo fmt.
Cada tipo de dato implementado debe ser colocado en una unidad de compilación (archivo fuente) independiente.

Entrega

La resolución del presente proyecto es en grupos de tres integrantes.

La entrega del proyecto se realizará mediante Github Classroom. Cada grupo tendrá un repositorio disponible para hacer diferentes commits con el objetivo de resolver el problema propuesto. Se recomienda iniciar tempranamente y hacer commits pequeños agreguen funcionalidad incrementalmente. Se podrán hacer commits hasta el día de la entrega a las 19 hs Arg, luego el sistema automáticamente quitará el acceso de escritura.

Evaluación

Principios teóricos y corrección de bugs

En caso de que la solución no se comportara de forma esperada, deberán poder explicar las causas y sus posibles rectificaciones.

Casos de prueba

Se someterá a la aplicación a diferentes casos de prueba que validen la correcta aplicación de las herramientas de concurrencia.

Informe

El informe debe estar estructurado profesionalmente y debe poder dar cuenta de las decisiones tomadas para implementar la solución.

Organización del código

El código debe organizarse respetando los criterios de buen diseño y en particular aprovechando las herramientas recomendadas por Rust. Se prohibe el uso de bloques unsafe.

Tests automatizados

La presencia de tests automatizados que prueben diferentes casos, en especial sobre el uso de las herramientas de concurrencia es un plus.

Presentación en término

El trabajo deberá entregarse para la fecha estipulada. La presentación fuera de término sin coordinación con antelación con el profesor influye negativamente en la nota final.

1er Cuatrimestre 2022

Trabajo Práctico

Fecha de Entrega: 28 de junio de 2022

Introducción

AlGlobo.com es un nuevo sitio de venta de pasajes online. Gracias al fin de la pandemia ha empezado a crecer fuertemente y necesitan escalar su sistema de procesamiento de pagos.

Para ello desean reemplazar una implementación monolítica actual con un microservicio en Rust que se encarge especificamente de este proceso.

Objetivo

Deberán implementar un conjunto de aplicaciones en Rust que modele el sistema de procesamiento de pagos de AlGlobo.com.

Se debe implementar un proceso para cada una de las entidades intervinientes y estas se comunicarán entre sí por sockets.

Se debe poder simular la salida de servicio de cualquiera de los procesos y réplicas de forma aleatoria o voluntaria, mostrando que el sistema en su conjunto sigue funcionando.

Requerimientos

El proceso de pagos se compone de la siguiente manera:

Intervienen 4 entidades: AlGlobo.com, el banco, la aerolínea y el hotel.
Existe una cola de pagos a procesar que se lee desde un archivo.
AlGlobo.com debe coordinar el pago informando el monto a cobrar a cada entidad de forma concurrente.
Cada entidad puede aleatoriamente procesar correctamente el cobro o no.
Si alguna falla, se debe mantener la transaccionalidad y por lo tanto revertir o cancelar apropiadamente.
Las fallas se guardan en un archivo de fallas para su posterior procesamiento manual. Debe implementarse una utilidad que permita reintentar manualmente cada pedido fallado.
El sistema de AlGlobo.com es de misión crítica y por lo tanto debe mantener varias réplicas en línea listas para continuar el proceso, aunque solo una de ellas se encuentra activa al mismo tiempo. Para ello utiliza un algoritmo de elección de líder y mantiene sincronizado entre las réplicas la información del la transacción actual.
La aplicación de AlGlobo.com esta basada internamente en el modelo de Actores, utilizando el framework Actix.
Todas las aplicaciones deben escribir un archivo de log con las operaciones que se realizan y sus resultados.
El sistema mantendrá estadísticas operacionales. Para ello debe calcular el tiempo medio que toma un pago en procesarse desde que ingresa el pedido hasta que es finalmente procesado por todas las entidades.

Requerimientos no funcionales

Los siguientes son los requerimientos no funcionales para la resolución de los ejercicios:

El proyecto deberá ser desarrollado en lenguaje Rust, usando las herramientas de la biblioteca estándar.
No se permite utilizar crates externos, salvo los explícitamente mencionados.
El código fuente debe compilarse en la última versión stable del compilador y no se permite utilizar bloques unsafe.
El código deberá funcionar en ambiente Unix / Linux.
El programa deberá ejecutarse en la línea de comandos.
La compilación no debe arrojar warnings del compilador, ni del linter clippy.
Las funciones y los tipos de datos (struct) deben estar documentadas siguiendo el estándar de cargo doc.
El código debe formatearse utilizando cargo fmt.
Cada tipo de dato implementado debe ser colocado en una unidad de compilación (archivo fuente) independiente.

Entrega

La resolución del presente proyecto es en grupos de tres integrantes.

La entrega del proyecto comprende lo siguiente:

Informe, se deberá presentar en forma digital (PDF) enviado por correo electrónico a la dirección: pdeymon@fi.uba.ar
El código fuente de la aplicación, que se entregará únicamente por e-mail. El código fuente debe estar estructurado en un proyecto de cargo, y se debe omitir el directorio target/ en la entrega. El informe a entregar debe contener los siguientes items:
- Una explicación del diseño y de las decisiones tomadas para la implementación de la solución.
- Detalle de resolución de la lista de tareas anterior.
- Diagrama que refleje los threads, el flujo de comunicación entre ellos y los datos que intercambian.
- Diagramas de entidades realizados (structs y demás).

Criterios de evaluación

Presentación, principios teóricos y defensa de bugs potenciales

Los alumnos presentarán el código de su solución en vivo en una reunión sincrónica, con foco en el uso de las diferentes herramientas de concurrencia. Deberán poder explicar desde los conceptos teóricos vistos en clase cómo se comportará potencialmente su solución ante problemas de concurrencia (por ejemplo ausencia de deadlocks).

En caso de que la solución no se comportara de forma esperada, deberán poder explicar las causas y sus posibles rectificaciones.

Casos de prueba en vivo

Durante la presentación se someterá a la aplicación a diferentes casos de prueba que validen la correcta aplicación de las herramientas de concurrencia.

Informe

El informe debe estar estructurado profesionalmente y debe poder dar cuenta de las decisiones tomadas para implementar la solución.

Se debe detallar en un diagrama, las entidades desarrolladas, las herramientas de concurrencia empleadas. Así como también los threads y formas de comunicación entre ellos. Se debe poder entender qué mensajes datos entre ellos y de qué forma.

Organización del código

El código debe organizarse respetando los criterios de buen diseño y en particular aprovechando las herramientas recomendadas por Rust (i.e. no utilizar unsafe)

Tests automatizados

La presencia de tests automatizados que prueben diferentes casos, en especial sobre el uso de las herramientas de concurrencia es un plus.

Presentación en término

El trabajo deberá entregarse para la fecha estipulada. La presentación fuera de término sin coordinación con antelación con el profesor influye negativamente en la nota final.

Participación individual

Si bien el trabajo es grupal, la nota es individual y la participación del alumno durante la presentación influye en su nota final.

Finales Julio/Agosto 2022

Los exámenes finales del periodo julio/agosto 2022 serán de forma presencial en la sede de Paseo Colón, en las siguientes fechas:

9509 // 7559 Técnicas de Programación Concurrente I:

martes 26/7 a las 18 hs
martes 2/8 a las 18 hs
martes 9/8 a las 18 hs
martes 16/8 a las 18 hs
jueves 25/8 a las 18 hs

Se evaluará de forma conceptual los temas tratados especialmente en la segunda parte de la materia (esto incluye responder preguntas conceptuales, desarrollos teóricos del tema o incluso desarrollar algo de código fuente para ilustrar un tema o responder algo solicitado).

2do Cuatrimestre 2021

Trabajo Práctico

Fecha de Entrega: 26 de octubre de 2021

Introducción

AlGlobo.com es un nuevo sitio de venta de pasajes online. Gracias al fin de la pandemia ha empezado a crecer fuertemente y necesitan escalar su proceso de reservas.

Para ello desean reemplazar una implementación monolítica actual con un microservicio en Rust que se encarge especificamente de este proceso.

Objetivo

Deberán implementar una aplicación en Rust que modele el sistema de reservas de AlGobo.com. Los pedidos de reserva se leerán desde un archivo y el webservice de cada aerolínea se simulará con sleeps aleatorios, y su resultado utilizando también variables aleatorias (random).

Requerimientos

El proceso de reserva se compone de la siguiente manera:

El pedido de reserva ingresa al sistema e indica aeropuerto de origen, de destino, aerolínea preferida y si la reserva es por paquete o solo vuelo.
El pedido se debe enviar a la aerolínea correspondiente. Para ello se comunica con un webservice específico de la misma. Por motivos de rate limiting, cada webservice no puede realizar mas de N pedidos concurrentes (es un límite configurable). Tener en cuenta que la cantidad de aerolíneas con las que se comunica el sistema debe poder crecer con un esfuerzo mínimo.
La aerolínea puede aceptar el pedido o recharzarlo. Si es rechazado, el sistema debe esperar X segundos para reintentar (el tiempo debe ser configurable).
En el caso de que la reserva sea por paquete, el pedido se debe enviar también al webservice de hoteles. El resultado final de la reserva entonces necesitará que ambos pedidos (hotel y aerolinea) se completen. Por suerte las reservas de hoteles nunca se rechazan.
El sistema debe mantener estadísticas de las rutas más solicitadas, que luego se utilizan para realizar ofertas. Para ello debe mantener un conteo de la cantidad de reservas realizadas de cada ruta y poder informar periódicamente las 10 más solicitadas.
Además el sistema mantendrá estadísticas operacionales. Para ello debe calcular el tiempo medio que toma una reserva desde que ingresa el pedido hasta que es finalmente aceptada.
Se debe escribir un archivo de log con las operaciones que se realizan y sus resultados.

Parte A

Implementar la aplicación utilizando las herramientas de concurrencia de la biblioteca standard de Rust vistas en clase: Mutex, RwLock, Semáforos (del crate std-semaphore), Channels, Barriers y Condvars.

Parte B

Implementar la aplicación basada en el modelo de Actores, utilizando el framework Actix.

Puntos extra

Utilizar Tokio HTTP y/o Actix web para recibir requests reales y Apache AB para generarlos en lugar de leerlos de un archivos.

Requerimientos no funcionales

Los siguientes son los requerimientos no funcionales para la resolución de los ejercicios:

El proyecto deberá ser desarrollado en lenguaje Rust, usando las herramientas de la biblioteca estándar.
No se permite utilizar crates externos, salvo los explícitamente mencionados.
El código fuente debe compilarse en la última versión stable del compilador y no se permite utilizar bloques unsafe.
El código deberá funcionar en ambiente Unix / Linux.
El programa deberá ejecutarse en la línea de comandos.
La compilación no debe arrojar warnings del compilador, ni del linter clippy.
Las funciones y los tipos de datos (struct) deben estar documentadas siguiendo el estándar de cargo doc.
El código debe formatearse utilizando cargo fmt.
Cada tipo de dato implementado debe ser colocado en una unidad de compilación (archivo fuente) independiente.

Entrega

La resolución del presente proyecto es en grupos de tres integrantes.

La entrega del proyecto comprende lo siguiente:

Informe, se deberá presentar en forma digital (PDF) enviado por correo electrónico a la dirección: pdeymon@fi.uba.ar
El código fuente de la aplicación, que se entregará únicamente por e-mail. El código fuente debe estar estructurado en un proyecto de cargo, y se debe omitir el directorio target/ en la entrega. El informe a entregar debe contener los siguientes items:
- Una explicación del diseño y de las decisiones tomadas para la implementación de la solución.
- Detalle de resolución de la lista de tareas anterior.
- Diagrama que refleje los threads, el flujo de comunicación entre ellos y los datos que intercambian.
- Diagramas de entidades realizados (structs y demás).

Criterios de evaluación

Presentación, principios teóricos y defensa de bugs potenciales

En caso de que la solución no se comportara de forma esperada, deberán poder explicar las causas y sus posibles rectificaciones.

Casos de prueba en vivo

Durante la presentación se someterá a la aplicación a diferentes casos de prueba que validen la correcta aplicación de las herramientas de concurrencia.

Informe

El informe debe estar estructurado profesionalmente y debe poder dar cuenta de las decisiones tomadas para implementar la solución.

Organización del código

El código debe organizarse respetando los criterios de buen diseño y en particular aprovechando las herramientas recomendadas por Rust (i.e. no utilizar unsafe)

Tests automatizados

La presencia de tests automatizados que prueben diferentes casos, en especial sobre el uso de las herramientas de concurrencia es un plus.

Presentación en término

El trabajo deberá entregarse para la fecha estipulada. La presentación fuera de término sin coordinación con antelación con el profesor influye negativamente en la nota final.

Participación individual

Si bien el trabajo es grupal, la nota es individual y la participación del alumno durante la presentación influye en su nota final.

Trabajo Práctico

Fecha de Entrega: 14 de diciembre de 2021

Introducción

Continuamos desarrollando el backend de AlGlobo.com. En este caso vamos a trabajar con el sistema de procesamiento de pagos.

Requerimientos

El proceso de pagos se compone de la siguiente manera:

Intervienen 4 entidades: AlGlobo.com, el banco, la aerolínea y el hotel.
Existe una cola de pagos a procesar que se lee desde un archivo.
AlGlobo.com debe coordinar el pago informando el monto a cobrar a cada entidad de forma concurrente.
Cada entidad puede aleatoriamente procesar correctamente el cobro o no.
Si alguna falla, se debe mantener la transaccionalidad y por lo tanto revertir o cancelar apropiadamente.
Las fallas se guardan en un archivo de fallas para su posterior procesamiento manual. Debe implementarse una utilidad que permita reintentar manualmente cada pedido fallado.
El sistema de AlGlobo.com es de misión crítica y por lo tanto debe mantener varias réplicas en línea listas para continuar el proceso, aunque solo una de ellas se encuentra activa al mismo tiempo. Para ello utiliza un algoritmo de elección de líder y mantiene sincronizado entre las réplicas la información del la transacción actual.

Objetivo

Deberán implementar un conjunto de aplicaciones en Rust que modele el sistema de procesamiento de pagos de AlGlobo.com.

Se debe implementar un proceso para cada una de las entidades intervinientes y estas se comunicarán entre sí por sockets.

Se debe poder simular la salida de servicio de cualquiera de los procesos y réplicas de forma aleatoria o voluntaria, mostrando que el sistema en su conjunto sigue funcionando.

Requerimientos no funcionales

Los siguientes son los requerimientos no funcionales para la resolución de los ejercicios:

El proyecto deberá ser desarrollado en lenguaje Rust, usando las herramientas de la biblioteca estándar.
No se permite utilizar crates externos, salvo los explícitamente mencionados o autorizados expresamente a pedido por la cátedra.
El código fuente debe compilarse en la última versión stable del compilador y no se permite utilizar bloques unsafe.
El código deberá funcionar en ambiente Unix / Linux.
El programa deberá ejecutarse en la línea de comandos.
La compilación no debe arrojar warnings del compilador, ni del linter clippy.
Las funciones y los tipos de datos (struct) deben estar documentadas siguiendo el estándar de cargo doc.
El código debe formatearse utilizando cargo fmt.
Cada tipo de dato implementado debe ser colocado en una unidad de compilación (archivo fuente) independiente.

Entrega

La resolución del presente proyecto es en grupos de tres integrantes.

La entrega del proyecto comprende lo siguiente:

Informe, se deberá presentar en forma digital (PDF) enviado por correo electrónico a las direcciones: pdeymon@fi.uba.ar y ascarpinelli@fi.uba.ar
El código fuente de la aplicación, que se entregará únicamente por e-mail. El código fuente debe estar estructurado en un proyecto de cargo, y se debe omitir el directorio target/ en la entrega.
El informe a entregar debe contener los siguientes items:
- Una explicación del diseño y de las decisiones tomadas para la implementación de la solución.
- Detalle de resolución de la lista de tareas anterior.
- Diagrama que refleje los threads, el flujo de comunicación entre ellos y los datos que intercambian.
- Diagramas de entidades realizados (structs y demás).

Criterios de evaluación

Presentación, principios teóricos y defensa de bugs potenciales

En caso de que la solución no se comportara de forma esperada, deberán poder explicar las causas y sus posibles rectificaciones.

Casos de prueba en vivo

Durante la presentación se someterá a la aplicación a diferentes casos de prueba que validen la correcta aplicación de las herramientas de concurrencia.

Informe

El informe debe estar estructurado profesionalmente y debe poder dar cuenta de las decisiones tomadas para implementar la solución.

Organización del código

El código debe organizarse respetando los criterios de buen diseño y en particular aprovechando las herramientas recomendadas por Rust (i.e. no utilizar unsafe)

Tests automatizados

La presencia de tests automatizados que prueben diferentes casos, en especial sobre el uso de las herramientas de concurrencia es un plus.

Presentación en término

El trabajo deberá entregarse para la fecha estipulada. La presentación fuera de término sin coordinación con antelación con el profesor influye negativamente en la nota final.

Participación individual

Si bien el trabajo es grupal, la nota es individual y la participación del alumno durante la presentación influye en su nota final.

Finales Febrero/Marzo 2022

Los exámenes finales del periodo febrero/marzo 2022 serán de forma presencial en la sede de Paseo Colón, en las siguientes fechas:

9509 // 7559 Técnicas de Programación Concurrente I:

jueves 10/2 a las 18 hs
martes 15/2 a las 18 hs
martes 22/2 a las 18 hs
jueves 3/3 a las 18 hs
martes 8/3 a las 18 hs

1er Cuatrimestre 2021

Trabajo Práctico 1 - 1er Cuatrimestre 2021

Objetivo: Realizar un trabajo de investigación y desarrollo sobre un paper de uno de los temas tratados en la materia.

Tareas:

Seleccionar un paper de la lista siguiente.

Interpretarlo, relacionarlo con los temas que trabajamos en la materia.

Preparar una exposición en grupo para presentar frente a la clase.

Fechas de la exposición: 1ro y 2 de junio.

Lista de Papers

Modelo de actores: Adicionalmente, relacionarlo con el modelo de actores de Erlang.
- Actor Model of Computation
- An Actor-Based Programming System
Redes de Petri.
Monitores

Trabajo presentados

Grupo 1 - Redes de Petri: slides - ejemplos de código
Grupo 2 - Redes de Petri (ejemplos): slides - ejemplos XML para usar con el software Petri net Editor 2. Repositorio de problema de los Filósofos.
Grupo 4 - Redes de Petri: slides
Grupo 5 - Paper Dijkstra: slides

Buscador de Sinónimos Rústico - 1er Cuatrimestre 2021

Fecha de entrega: 29 de junio antes de las 19 hs.

Objetivo

El presente trabajo práctico tiene como objetivo implementar un software buscador de sinónimos de palabras.

Para ello se realizarán peticiones de varios sitios de Internet que ofrecen este servicio.

Requerimientos Funcionales

Se debe implementar un software para ser ejecutado en la consola de comandos que busque sinónimos de palabras en distintos sitios de Internet.

Se usarán los siguientes sitios que permiten buscar sinóminos de palabras en inglés:

Por ejemplo, para buscar sinónimos de "car", se debe invocar:

Nota: Estos tres proveedores de sinónimos son los que disponemos hoy en día. En un futuro se debería poder incorporar fácilmente nuevos proveedores, el único trabajo que se debería hacer es el parser específico de la respuesta, para extraer las palabras.

El programa debe recibir por parámetro la ruta a un archivo que contiene una lista de palabras sobre las que se quieren buscar sinónimos (una palabra por línea del archivo) y los parámetros de configuración de la ejecución, como se explica más adelante.

Para realizar las consultas de los sinónimos, se debe realizar un pedido (request) HTTP a cada una de las direcciones. Para eso, se debe utilizar el crate reqwest. Este crate debe ser usado en forma bloqueante (ver blocking).

Debe procesarse el texto de respuesta de cada una de las invocaciones (string) para extraer las palabras que son sinónimos. Para esto, debe utilizarse los métodos de String de la std del lenguaje.

Los resultados deben mostrarse de forma consolidada, sin repetir los resultados (en caso de que se encuentren en más de un sitio). Al lado de cada resultado se debe indicar entre paréntesis, en cuántos sitios apareció ese valor.

Las parámetros que se debe poder configurar son:

Cantidad máxima de pedidos a los sitios web (requests) a procesar de forma concurrente.
Tiempo de espera mínimo entre dos invocaciones al mismo sitio de sinónimos.

Se debe divir el programa en hilos de ejecución (threads) que sean lo más chico posibles y con una responsabilidad acotada, que permitan realizar las diversas tareas de forma concurrente.

Se debe escribir un archivo de log con las operaciones que se realizan y sus resultados.

Parte A

Implementar el programa utilizando las herramientas de concurrencia de la biblioteca standard de Rust vistas en clase: Mutex, RwLock, Semáforos (del crate std-semaphore), Channels, Barriers y Condvars.

Parte B

Implementar el programa basado en el modelo de Actores, utilizando el framework Actix.

Requerimientos no funcionales

Los siguientes son los requerimientos no funcionales para la resolución de los ejercicios:

El proyecto deberá ser desarrollado en lenguaje Rust, usando las herramientas de la biblioteca estándar.
No se permite utilizar crates externos, salvo los explícitamente mencionados.
El código fuente debe compilarse en la última versión stable del compilador y no se permite utilizar bloques unsafe.
El código deberá funcionar en ambiente Unix / Linux.
El programa deberá ejecutarse en la línea de comandos.
La compilación no debe arrojar warnings del compilador, ni del linter clippy.
Las funciones y los tipos de datos (struct) deben estar documentadas siguiendo el estándar de cargo doc.
El código debe formatearse utilizando cargo fmt.
Cada tipo de dato implementado debe ser colocado en una unidad de compilación (archivo fuente) independiente.

Tareas a Realizar

A continuación se listan las tareas a realizar para completar el desarrollo del proyecto:

Dividir el proyecto en threads. El objetivo es lograr que la simulación esté conformada por un conjunto de hilos de ejecución que sean lo más sencillos posible.
Una vez obtenida la división en threads, establecer un esquema de comunicación entre ellos teniendo en cuenta los requerimientos de la aplicación. ¿Qué threads se comunican entre sı́? ¿Qué datos necesitan compartir para poder trabajar?
Realizar la codificación de la aplicación. El código fuente debe estar documentado.
Implementar tests unitarios de las funciones que considere relevantes.

Entrega

La resolución del presente proyecto es en grupos de tres integrantes.

La entrega del proyecto comprende lo siguiente:

Informe, se deberá presentar en forma digital (PDF) enviado por correo electrónico a la dirección: pdeymon@fi.uba.ar
El código fuente de la aplicación, que se entregará únicamente por e-mail. El código fuente debe estar estructurado en un proyecto de cargo, y se debe omitir el directorio target/ en la entrega. El informe a entregar debe contener los siguientes items:
- Una explicación del diseño y de las decisiones tomadas para la implementación de la solución.
- Detalle de resolución de la lista de tareas anterior.
- Diagrama que refleje los threads, el flujo de comunicación entre ellos y los datos que intercambian.
- Diagramas de entidades realizados (structs y demás).

Blockchain Rústica - 1er Cuatrimestre 2021

Fecha de entrega: 27 de julio antes de las 19 hs.

Objetivo

El objetivo del presente trabajo consiste en aplicar los conceptos estudiados de Concurrencia Distribuida para implementar una funcionalidad de blockchain simplificada.

Introducción

La blockchain es una forma de almacenar información, que consiste en un registro único, consensuado y distribuido en varios nodos de una red. A grandes rasgos su estructura es la de una cadena de bloques que están encadenados de forma sucesiva. Cada bloque contiene la información (a partir de un hash) del bloque que lo precede.

Se usa para almacenar información que no puede ser alterada, como es el caso de transacciones de criptomonedas. Se puede pensar como el libro contable donde se registra cada una de esas transacciones.

Requerimientos Funcionales

Se debe implementar una versión reducida y simplificada de una blockchain que permita almacenar las calificaciones de los estudiantes de la materia. Esta información debe poder ser escrita y leída.

Se debe respetar que cada registro sea un bloque de la blockchain y, por lo tanto, tenga información referente al bloque o los bloques precedentes.

Esta implementación debe funcionar como un conjunto de programas en ejecución que se comunican entre sí utilizando sockets sobre el protocolo TCP/IP. Se debe utilizar Sockets de la biblioteca standar del lenguaje Rust.

Para el agregado de un bloque nuevo, un nodo debe poder realizar las operaciones de forma exclusiva. Para esto, se debe implementar alguno de los algoritmos estudiados en la materia:

Algoritmo Centralizado
Algoritmo Distribuido
Algoritmo Token Ring

Una vez que se agrega un bloque nuevo, un nodo que cumple el rol de líder debe comunicar la operación a todos los demás. Para la elección del líder se debe implementar alguno de los algoritmos estudiados:

Algoritmo de Bully
Algoritmo Ring

Se debe poder simular la salida de servicio de los nodos de forma aleatoria o voluntaria. En particular, se debe poder observar que si sale de servicio el nodo que actúa como líder, se debe reiniciar el algoritmo de elección para reemplazarlo con uno nuevo.

Requerimientos no funcionales

Los siguientes son los requerimientos no funcionales para la resolución de los ejercicios:

El proyecto deberá ser desarrollado en lenguaje Rust, usando las herramientas de la biblioteca estándar.
No se permite utilizar crates externos.
El código fuente debe compilarse en la última versión stable del compilador y no se permite utilizar bloques unsafe.
El código deberá funcionar en ambiente Unix / Linux.
El programa deberá ejecutarse en la línea de comandos.
La compilación no debe arrojar warnings del compilador, ni del linter clippy.
Las funciones y los tipos de datos (struct) deben estar documentadas siguiendo el estándar de cargo doc.
El código debe formatearse utilizando cargo fmt.
Cada tipo de dato implementado debe ser colocado en una unidad de compilación (archivo fuente) independiente.

Tareas a Realizar

A continuación se listan las tareas a realizar para completar el desarrollo del proyecto:

Dividir el proyecto en procesos y threads. El objetivo es lograr procesos que cumplan un objetivo específico y que estos se conformen por un conjunto de hilos de ejecución que sean lo más sencillos posible.
Una vez obtenida la división en threads, establecer un esquema de comunicación entre ellos teniendo en cuenta los requerimientos de la aplicación. ¿Qué threads se comunican entre sı́? ¿Qué datos necesitan compartir para poder trabajar?
Realizar la codificación de la aplicación. El código fuente debe estar documentado.
Implementar tests unitarios de las funciones que considere relevantes.

Entrega

La resolución del presente proyecto es en grupos de tres integrantes.

La entrega del proyecto comprende lo siguiente:

Informe, se deberá presentar en forma digital (PDF) enviado por correo electrónico a la dirección: pdeymon@fi.uba.ar
El código fuente de la aplicación, que se entregará únicamente por e-mail. El código fuente debe estar estructurado en un proyecto de cargo, y se debe omitir el directorio target/ en la entrega. El informe a entregar debe contener los siguientes items:
- Una explicación del diseño y de las decisiones tomadas para la implementación de la solución.
- Detalle de resolución de la lista de tareas anterior.
- Diagrama que refleje los threads, el flujo de comunicación entre ellos y los datos que intercambian.
- Diagramas de entidades realizados (structs y demás).

Examen Final

La modalidad del examen final será de tipo remota. El estudiante debe escoger uno de los papers / artículos de la lista de abajo y preparar una exposición del mismo relacionada con los tema de la materia.

Asimismo, se evaluará con preguntas haciendo énfasis en los temas de Concurrencia Distribuida (ver desde la clase 8 en adelante).

Las fechas de examen están publicadas en la plataforma SIU Guaraní. Por favor, luego de inscribirse, enviar un correo electrónico para combinar la reunión por Google Meet.

Lista de papers:

Material Adicional

Videos

Multithreading Code - Computerphile

Bibliografía

La bibliografía recomendada de la materia es la siguiente

Rust
- Principles of Concurrent and Distributed Programming, M. Ben-Ari, Segunda edición (capítulos 1, 2, 6 y 7)
- Operating System Concepts, Ninth Edition, Abraham Silberschatz, Greg Gagne, and Peter Baer Galvin, Cap. 4.
- The Rust Programming Language
Fork Join
- Parallelization in Rust with fork-join and friends. Creating the ForkJoin framework, Master's thesis in Computer Science and Engineering. Linus Färnstrand
- Documentacion Crayon
- Documentacion CrossBeam
- A Multiprocessor System Design, M.E. Conway, 1963
- MapReduce: Simplified Data Processing on Large Clusters, Jeffrey Dean and Sanjay Ghemawat, 2014
- Dremel: Interactive Analysis of Web-Scale Datasets S. Melnik et al., 2010
Async
- Programming Rust: Fast, Safe Systems Development, 2nd Edition, Jim Blandy, Jason Orendorff, Leonora F. S. Tindall. 2021.
- Asynchronous Programming in Rust
Mutex
- Principles of Concurrent and Distributed Programming, M. Ben-Ari, Segunda edición (capítulos 1 y 2)
- Unix Network Programming, Interprocess Communications, W. Richard Stevens, segunda edición"
Semaphores, Barriers Condvars
- The Design of the Unix Operating System, Maurice Bach
- Sistemas Operativos Modernos, Tanenbaum, Capítulo 2.3
- The Little Book of Semaphores, Allen B. Downey
- Monitors: An Operating System Structuring Concept, C.A.R. Hoare, Communications of the ACM, 1974
- Concurrent control with ""readers"" and ""writers""
Channels and Actors
- Principles of Concurrent and Distributed Programming, M. Ben-Ari, Segunda edición (capítulos 6)
- The Complete Rust Programming Reference Guide, Rahul Sharma, Vesa Kaihlavirta, Claus Matzinger. An Actor-Based Programming System, Roy J. Byrd, Stephen E. Smith, S. Peter de Jong. IBM Thomas J. Watson Research Center, Yorktown Heights, New York 10598
- Seven Concurrency Models in Seven Weeks: When Threads Unravel (The Pragmatic Programmers), Paul Butcher
- Actix
- A Universal Modular ACTOR Formalism for Artificial Intelligence. C. Hewitt, P. Bishop, and R. Steiger. IJCAI , page 235-245. William Kaufmann, (1973 )
- The Drinking Philosophers Problem. Chandy, K.M.; Misra, J. (1984). ACM Transactions on Programming Languages and Systems
Sockets
- Distributed Operating Systems, Andrew S. Tanenbaum, capítulo 3
- Computer Networks, Andrew S. Tanenbaum y David J. Wetherall, quinta edición
- Unix Network Programming - Volume 1 - The Sockets Networking API, Richard Stevens, tercera edición
- Ricart, Glenn; Agrawala, Ashok K. (1 January 1981). ""An optimal algorithm formutual exclusion in computer networks"". Communications of the ACM. 24 (1):9–17 https://dl.acm.org/doi/abs/10.1145/358527.358537
- Tanenbaum. Distributed Systems: Principles and paradigmns. Capitulo 6 "
Elección de líder
- Distributed Operating Systems, Andrew S. Tanenbaum, capítulo 3
- Computer Networks, Andrew S. Tanenbaum y David J Wetherall, quinta edición
- The Complete Rust Programming Reference Guide, Rahul Sharma, Vesa Kaihlavirta, Claus Matzinger.
- Hector Garcia-Molina, Elections in a Distributed Computing System, IEEE Transactions on Computers, Vol. C-31, No. 1, January (1982) 48–59
- Tanenbaum. Distributed Systems: Principles and paradigmns. Capitulo 6"
Distributed Transactions
- Distributed Operating Systems, Andrew S. Tanenbaum, capítulo 3
- Computer Networks, Andrew S. Tanenbaum y David J. Wetherall, quinta edición
- Distributed Systems: Principles and Paradigms. Tanenbaum & Van Steem, Capitulo 8"
- Design and Analysis of Distributed Algorithms, Nicola Santoro

Concurrentes - FIUBA