{"id":21092055,"url":"https://github.com/matteoldani/da-project","last_synced_at":"2025-10-13T09:15:41.710Z","repository":{"id":132446056,"uuid":"541978196","full_name":"matteoldani/da-project","owner":"matteoldani","description":"Java implementation of FIFO Broadcast and Lattice Agreement in a distributed system","archived":false,"fork":false,"pushed_at":"2023-03-05T14:42:06.000Z","size":29411,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"master","last_synced_at":"2025-09-08T00:41:27.770Z","etag":null,"topics":["distributed-algorithms","distributed-systems"],"latest_commit_sha":null,"homepage":"","language":"Java","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/matteoldani.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2022-09-27T08:22:25.000Z","updated_at":"2023-03-05T14:45:24.000Z","dependencies_parsed_at":null,"dependency_job_id":"9d3c9b72-fb69-4a33-ab59-47b54981d074","html_url":"https://github.com/matteoldani/da-project","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/matteoldani/da-project","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/matteoldani%2Fda-project","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/matteoldani%2Fda-project/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/matteoldani%2Fda-project/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/matteoldani%2Fda-project/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/matteoldani","download_url":"https://codeload.github.com/matteoldani/da-project/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/matteoldani%2Fda-project/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":279014485,"owners_count":26085535,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-10-13T02:00:06.723Z","response_time":61,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["distributed-algorithms","distributed-systems"],"created_at":"2024-11-19T21:50:56.175Z","updated_at":"2025-10-13T09:15:41.673Z","avatar_url":"https://github.com/matteoldani.png","language":"Java","readme":"# Distributed Algorithms 2022/23 - EPFL\n\nThis repo holds my implementation of the project proposed in class CS-451 (Distributed Algorithms) at EPFL.\nThe implementation of the first part of the project (FIFO Broadcast) is inside `fifo_broadcast`. The second one (Lattice Agreement), which is partially build on the previous one, is inside `lattice_agreement`.\n\n# Overview\nThe goal of this practical project is to implement certain building blocks necessary for a decentralized system. To this end, some underlying abstractions will be used:\n\n  - Perfect Links (submission #1),\n  - Best-effort Broadcast,\n  - Uniform Reliable Broadcast,\n  - FIFO Broadcast (submission #2),\n  - Lattice Agreement (submission #3)\n\nVarious applications (e.g., a payment system) can be built upon these lower-level abstractions. We will check your submissions (see [Submissions](#submissions)) for correctness and performance as part of the final evaluation.\n\nFor a quick description of the project, refer to [these](https://docs.google.com/presentation/d/1VkJSjSkLK29qQjlxUWtoqp20I-An72BZI_2CaLVh8Cs) slides.\n\nFor a quick overview of the project's evaluation, refer to [these](https://docs.google.com/presentation/d/143jE90eoQbjwzE8BBXm865sMDZnhZNUcv9_zuP6o7WM) slides.\n\nAll details about the project are given below.\n\n# Project Requirements\n\n## Basics\nThe implementation must take into account that **messages** exchanged between processes **may be dropped, delayed or reordered by the network**. The execution of processes may be paused for an arbitrary amount of time and resumed later. Processes may also fail by crashing at arbitrary points of their execution.\n\n## Programming Languages\nIn order to have a fair comparison among implementations, as well as provide support to students, the project must be developed using the following tools:\n\n*Allowed programming language*:\n  - C11 and/or C++17\n  - Java\n\n*Build system*:\n  - CMake for C/C++\n  - Maven for Java\n\nNote that we provide you a template for both C/C++ and Java. It is mandatory to use the template in your project. You are **NOT** allowed to change any of the file names or the function signatures in this template.\n\nAllowed 3rd party libraries: **None**. You are not allowed to use any third party libraries in your project. C++17 and Java 11 come with an extensive standard library that can easily satisfy all your needs. However, you allowed to use code from the internet (e.g., a publicly available [skip list](https://en.wikipedia.org/wiki/Skip_list)), as long as you give appropriate credit.\n\n## Communication Primitive\nInter-process point-to-point messages (at the low level) must be carried exclusively by UDP packets in their most basic form, not utilizing any additional features (e.g., any form of feedback about packet delivery) provided by the network stack, the operating system or external libraries. Everything must be implemented on top of these low-level point to point messages.\n\n## Application messages\nThe messages exchanged by processes contain a payload, which differs based on the submission.\nFor the first two submission, the payload is an integer number. For the third submission is a list of integer numbers.\nApart from the payload, the exchanged messages should also contain other metadata information which is necessary to implement the required abstractions.\nWe ensure that a messages up to 64KiB can fit in a single UDP packet, thus a sane implementation should not worry about [message fragmentation](https://en.wikipedia.org/wiki/Maximum_transmission_unit).\n\n## Code structure\nWe provide you a template for both C/C++ and Java, which you should use in your project. The template has a certain structure that is explained below:\n\n### For C/C++:\n```bash\n.\n├── bin\n│   ├── deploy\n│   │   └── README\n│   ├── logs\n│   │   └── README\n│   └── README\n├── build.sh\n├── cleanup.sh\n├── CMakeLists.txt\n├── run.sh\n└── src\n    ├── CMakeLists.txt\n    └── ...\n```\nYou can run:\n  - `build.sh` to compile your project\n  - `run.sh \u003carguments\u003e` to run your project\n  - `cleanup.sh` to delete the build artifacts. We recommend running this command when submitting your project for evaluation.\n\nYou should place your source code under the `src` directory. You are not allowed to edit any files outside the `src` directory. Furthermore, you are not allowed to edit sections of `src/CMakeLists.txt` that are marked as \"DO NOT EDIT\". Apart from these restrictions, you are completely free on how to structure the source code inside `src`. Yet, we encourage modular design. This will make your code cleaner and the project easier. It will also help you spot bugs.\n\nThe template already includes some source code under `src`, that will help you with parsing the arguments provided to the executable (see below).\n\nFinally, **your executable should not create/use directories named \"deploy\" and/or \"logs\"** in the current working directory. These directories are reserved for evaluation!\n\n### For Java:\n```sh\n.\n├── bin\n│   ├── deploy\n│   │   └── README\n│   ├── logs\n│   │   └── README\n│   └── README\n├── build.sh\n├── cleanup.sh\n├── pom.xml\n├── run.sh\n└── src\n    └── main\n        └── java\n            └── cs451\n                └── ...\n```\nThe restrictions for the C/C++ template also apply here. The difference is that you are only allowed to place your source code under `src/main/java/cs451`.\n\n## Application Interface\nThe templates provided come with a command line interface (CLI) that you should use in your deliverables. The implementation for the CLI is given to you for convenience. You are allowed to make any modifications to it (e.g., add additional argument to help you debug your implementation), as long as it complies to the specification.\n\nThe supported arguments are:\n```sh\n./run.sh --id ID --hosts HOSTS --output OUTPUT CONFIG\n```\n\nWhere:\n  - `ID` specifies the unique identifier of the process. In a system of `n` processes, the identifiers are `1`...`n`.\n  - `HOSTS` specifies the path to a file that contains the information about every process in the system, i.e., it describes the system membership. The file contains as many lines as processes in the system. A process identity consists of a numerical process identifier, the IP address or name of the process and the port number on which the process is listening for incoming messages. The entries of each process identity are separated by a single space character. The following is an example of the contents of a `HOSTS` file for a system of 5 processes:\n  ```\n1 localhost 11001\n2 localhost 11002\n3 localhost 11003\n4 localhost 11004\n5 localhost 11005\n  ```\n  **Note**: The processes should listen for incoming messages in the port range `11000` to `11999` inclusive. Each process should use only 1 port.\n\n  - `OUTPUT` specifies the path to a text file where a process stores its output. The formatting of the output text file depends on the submission. \n\n- `CONFIG` specifies the path to a file that contains additional information for the experimented abstraction (e.g., how many message to broadcast).\n\n## Process Crashes\nWe simulate process crashes by relying on Linux's signals.\nA process that receives a `SIGTERM` or `SIGINT` signal must immediately stop its execution with the exception of writing to an output log file (described above). In particular, it must not send or handle any received network packets. You can assume that at most a minority (e.g., 1 out of 3; 2 out of 5; 4 out of 10, ...) processes may crash in one execution.\nYou can assume that a process crash will be simulated only by the `SIGINT` or `SIGTERM` signals.\n\n**Note:** The most straight-forward way of logging the output is to append a line to the output file on every broadcast or delivery event. However, this may harm the performance of the implementation. You may consider more sophisticated logging approaches, such as storing the logs in memory and periodically write them to the output file. Also note that even a crashed process needs to output the sequence of events that occurred before the crash. Remember that writing to files is the only action we allow a process to do after receiving a `SIGINT` or `SIGTERM` signal.\n\n## Applications\n### Perfect Links application\nIn this application (submission #0) a set of processes exchange messages using perfect links.\nIn particular a single process only receives messages while the rest of processes only send messages.\nThe communication of every sender with the receiver is realized using the perfect links abstraction.\n\nBelow are the details for the `CONFIG` and `CONFIG` files of this submission.\n\n#### The `CONFIG` file\n  - The config file contains two integers `m i` in its first line. The integers are separated by a single space character. `m` defines how many messages each sender process should send. `i` is the index of the receiver process. The receiver process only receives messages while the sender processes only send messages. All `n-1` sender processes, send `m` messages each.\n  Sender processes send messages `1` to `m` in order.\n\n#### The `OUTPUT` file\nThe output file contains a log of send/receive events. Each event is represented by one line of the output file, terminated by a Unix-style line break `\\n`. There are two types of events to be logged:\n    - sending of an application message, using the format `b`*`seq_nr`*, where `seq_nr` is the sequence number of the message. These messages are numbered sequentially at each process, starting from `1`.\n    - delivery of an application message, using the format `d`*`sender`* *`seq_nr`*, where *`sender`* is the number of the process that sent the message and *`seq_nr`* is the sequence number of the message (as numbered by the sending process).\n\nAn example of the content of an output file (ellipsis denotes skipped content)\n```\nb 1\nb 2\nb 3\n...\n```\n\n*Note*: By default, the payload carried by an application message is only the sequence number of that message. Though the payload is known in advance, your implementation should not utilize this information. In other words, your implementation should be agnostic to the contents of the payload. For example, your implementation should work correctly if the payload is arbitrary text instead of sequential numbers. In addition, your implementation should not rely on the fact that the total number of messages (to be broadcast) is known in advance, i.e., your implementation should work correctly if messages arrive as a stream.\n\n### FIFO Broadcast application\nThis is the same abstraction as the one thought in class. Informally, Every process is both broadcasting and delivering messages from every other process (including itself). You must implement FIFO broadcast on top of Uniform Reliable Broadcast (URB).\n\n#### The `CONFIG` file\n  - The config file contains an integer `m` in its first line. `m` defines how many messages each process should broadcast. Processes broadcast messages `1` to `m` in order.\n\n#### The `OUTPUT` file\nThe output file contains a log of broadcast/deliver events. Each event is represented by one line of the output file, terminated by a Unix-style line break `\\n`. There are two types of events to be logged:\n    -  broadcast of and application message, using the format `b`*`seq_nr`*,\n  where `seq_nr` is the sequence number of the message. These messages are numbered sequentially at each process, starting from `1`.\n    - delivery of and application message, using the format `d`*`sender`* *`seq_nr`*, where *`sender`* is the number of the process that broadcast the message and *`seq_nr`* is the sequence number of the message (as numbered by the broadcasting process).\n\nAn example of the content of an output file (ellipses denote skipped content in this example)\n```\nb 1\nb 2\nb 3\n...\nd 2 1\n...\nd 4 2\n...\nb 4\n```\n\n### Lattice Agreement\nLattice Agreement is a strictly weaker than consensus, as it can be solved in the asynchronous model. The formal specification, as well as an algorithm that implements it, is provided in [moodle](https://moodle.epfl.ch/mod/resource/view.php?id=1228278). In a nutshell, processes propose sets of values and also decide set of values.\nHowever, notice that the provided algorithm is single-shot, i.e., processes propose and decide only once.\n\nThe goal of this submission is to implement multi-shot lattice agreement, in which processes decide on a sequence of proposals.\nIn other words, in multi-shot lattice agreement, processes run single-shot lattice agreement on a series of slots. The specification of \nlattice agreement must be satisfied individually in every every slot.\n\n#### The `CONFIG` file\n  - The config file consists of multiple lines.\n  - The first line contains three integers, `p vs ds` (separated by single spaces). `p` denotes the number of proposals for each process, `vs` denotes the maximum number of elements in a proposal, and `ds` denotes the maximum number of distinct elements across all proposals of all processes.\n  - The subsequent `p` lines contain proposals. Each proposal is a set of positive integers, written as a list of integers separated by single spaces. Every line can have up to `vs` integers.\n\nAn example of the content of a config file (ellipsis denotes skipped content)\n```\n100 3 5\n478163327\n958682846 478163327 1181241943\n478163327 958682846\n107420369\n958682846\n478163327 107420369 1181241943\n...\n```\n\n*Note*: In the previous submissions, every process received the same config file. In this submission, every process receives a different config file. These config files have identical first lines and differ in the rest of the lines.\n\n#### The `OUTPUT` file\nThe text file contains a log of decisions. Each decision is represented by one line of the output file, \nby a Unix-style line break `\\n`. Given that proposals are set of integers, so are decisions. Thus, a decision **should** contain a list of integers separated by single spaces (and terminated by a Unix-style line break `\\n`). The order of the lines in the output file must be the same as the order of the lines (proposals) in the config file.\n\nAn example of the content of an output file (ellipses denote skipped content in this example)\n```\n478163327 1181241943 1051802512\n478163327 958682846 1181241943\n478163327 958682846 1181241943\n107420369\n107420369 958682846\n478163327 958682846 107420369 1181241943\n...\n```\n\n## Compilation\nAll submitted implementations will be tested using Ubuntu 18.04 running on a 64-bit architecture.\nThese are the specific versions of toolchains where you project will be tested upon:\n  - gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0\n  - g++ (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0\n  - cmake version 3.10.2\n  - OpenJDK Runtime Environment (build 11.0.8+10-post-Ubuntu-0ubuntu118.04.1)\n  - Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)\n\n## Project Development\nYou can develop your project using the following ways:\n\n### Using the provided Virtual Machine (VM)\nThis is the recommended option.\n* It already includes the exact versions of the build tools mentioned previously.\n* We provide support for it.\n* Thus, students with limited programming knowledge are advised to use it.\n\nGet the VM Image from [here](https://github.com/LPD-EPFL/CS451-2022-project/blob/master/VM.txt) (Windows/Linux/Mac machines with Intel/AMD CPUs, as well as Mac machines with ARM CPUs).\n\n### Using the Docker container\nThis is recommended only to students with an existing knowledge in distributed programming.\n* It already includes the exact versions of the build tools mentioned previously.\n* It only works in Linux and Mac\n* We do not provide support for it.\n* Follow [these](https://github.com/LPD-EPFL/CS451-2022-project/tree/master/docker) instructions to build the container.\n\n### Doing it your way\nThis is not advised. Do it at your own risk.\n\n\n**Submissions that fail to compile will NOT be considered for grading. Similarly, submissions that fail to produce any output files or produce faulty output files (e.g., empty files) will NOT be graded.**\n\n\n## Running the project\nWe provide two ways of running your project. The first way is manually, which is useful for early development and debugging. The second way is automatic, using the provided python [script](https://github.com/LPD-EPFL/CS451-2022-project/blob/master/tools/stress.py).\n\n### Manual execution\n\n#### Perfect Links application\nThe following example builds and starts 3 processes (run from within the `template_cpp` or the `template_java` directory):\n```sh\n# Build the application:\n./build.sh\n\n# In first terminal window:\n./run.sh --id 1 --hosts ../example/hosts --output ../example/output/1.output ../example/configs/perfect-links.config\n\n# In second terminal window:\n./run.sh --id 2 --hosts ../example/hosts --output ../example/output/2.output ../example/configs/perfect-links.config\n\n# In third terminal window:\n./run.sh --id 3 --hosts ../example/hosts --output ../example/output/3.output ../example/configs/perfect-links.config\n\n# Wait enough time for all processes to finish processing messages.\n# Type Ctrl-C in every terminal window to create the output files.\n# Of course, you will NOT find any output files after running this because there is nothing implemented now!\n```\n\n#### FIFO Broadcast application\nThe following example builds and starts 3 processes (run from within the `template_cpp` or the `template_java` directory):\n```sh\n# Build the application:\n./build.sh\n\n# In first terminal window:\n./run.sh --id 1 --hosts ../example/hosts --output ../example/output/1.output ../example/configs/fifo-broadcast.config\n\n# In second terminal window:\n./run.sh --id 2 --hosts ../example/hosts --output ../example/output/2.output ../example/configs/fifo-broadcast.config\n\n# In third terminal window:\n./run.sh --id 3 --hosts ../example/hosts --output ../example/output/3.output ../example/configs/fifo-broadcast.config\n\n# Wait enough time for all processes to finish processing messages.\n# Type Ctrl-C in every terminal window to create the output files.\n```\n\n#### Lattice Agreement\nThe following example builds and starts 3 processes (run from within the `template_cpp` or the `template_java` directory):\n```sh\n# Build the application:\n./build.sh\n\n# In first terminal window:\n./run.sh --id 1 --hosts ../example/hosts --output ../example/output/1.output ../example/configs/lattice-agreement-1.config\n\n# In second terminal window:\n./run.sh --id 2 --hosts ../example/hosts --output ../example/output/2.output ../example/configs/lattice-agreement-2.config\n\n# In third terminal window:\n./run.sh --id 3 --hosts ../example/hosts --output ../example/output/3.output ../example/configs/lattice-agreement-3.config\n\n# Wait enough time for all processes to finish processing messages.\n# Type Ctrl-C in every terminal window to create the output files.\n```\n\n### Automatic execution\nDepending on the submission, use the appropriate command below:\n```sh\n./stress.py perfect -r RUNSCRIPT -l LOGSDIR -p PROCESSES -m MESSAGES\n./stress.py fifo -r RUNSCRIPT -l LOGSDIR -p PROCESSES -m MESSAGES\n./stress.py agreement -r RUNSCRIPT -l LOGSDIR -p PROCESSES -n PROPOSALS -v PROPOSAL_MAX_VALUES -d PROPOSALS_DISTINCT_VALUES\n\n```\n\nWhere:\n* `RUNSCRIPT` is the path to *run.sh*. Remember to build your project first!\n* `LOGSDIR` is the path to a directory where stdout/stderr and output of each process will be stored.  It also stores generated HOSTS and CONFIG files. The directory must exist as it will not be created for you.\n* `PROCESSES` (for `perfect`, `fifo` and `agreement`) specifies the number of processes spawn during validation.\n* `MESSAGES` (for `perfect` and `fifo`) specifies the number of messages each process is broadcasting.\n* `PROPOSALS` (for `agreement`) specifies the number of proposals each process is proposing.\n* `PROPOSAL_MAX_VALUES` (for `agreement`) specifies the maximum size of the proposal set, i.e., the maximum number of integers that each proposal contains.\n* `PROPOSALS_DISTINCT_VALUES` (for `agreement`) specifies the number of distinct elements across all proposals of all processes, i.e., it specifies the maximum size of the union of all proposals.\n\nYou can edit `testConfig` at the bottom of `stress.py` in order to test different scenarios.\n```py\ntestConfig = {\n  'concurrency' : 8, # How many threads are interfering with the running processes.\n  'attempts' : 8, # How many successful operations (SIGCONT, SIGSTOP, SIGTERM) each thread will attempt before stopping. Threads stop if a minority of processes has been terminated.\n  'attemptsDistribution' : { # Each thread selects a process randomly and issues one of these operations with the given probability.\n    'STOP': 0.48,\n    'CONT': 0.48,\n    'TERM':0.04\n    }\n}\n```\n\nTo change the rate at which interfering threads interfere with the processes modify this line: \n```py\ntime.sleep(float(random.randint(50, 500)) / 1000.0)\n```\nunder the `StressTest` class.\n\n\n## Limits\nThe entire project implements abstractions that operate in the asynchronous model, i.e., there is no bound in processing and communication delays. However, during the evaluation of the projects we set a maximum execution time limit.\n\nIn particular, we assume that every broadcast message takes at most 1 second to be delivered when:\n* the network is not delaying/dropping/reordering packets.\n* Processes are not delayed (e.g., with SIGSTOP).\n\nWe adjust this number accordingly when the network is not well behaving.\n\nAdditionally, we enforce certain limitations during testing:\n* You are given 2 CPU cores.\n* You are given a maximum of 64MiB per process.\n* You are allowed to use a maximum of 8 threads per process.\n\nPoorly engineered implementations may fail some tests due to these limitations (e.g., if you create a new thread for every message you broadcast).\n\nFinally, two more limitation are in place:\n* Your output files cannot exceed 16MiB.\n* Your console output files are trimmed if they exceed 1MiB.\n\nThese are only to guard against programming mistakes (e.g., infinite loop in the output that depletes disk space). You should not be worried about them.\n\n## Cooperation\nThis project is meant to be completed individually. Copying from others is prohibited. You are free (and encouraged) to discuss the projects with others, but the submitted source code must be the exclusive work yours. Multiple copies of the same code will be disregarded without investigating which is the \"original\" and which is the \"copy\". Furthermore, please give appropriate credit to pieces of code you found online (e.g. in stackoverflow).\n\n*Note*: code similarity tools will be used to check copying.\n\n## Submissions and Grading\n### Grading\nThis project accounts for 30% of the final grade and comprises three submissions:\n  - A runnable application implementing Perfect Links (20%),\n  - A runnable application implementing FIFO Broadcast (40%), and\n  - The last submission accounts for 40%.\n\nNote that these submissions are *incremental*. This means that your work towards the first will help you in your work towards the second.\n\n### Deadlines\n* Perfect Links: October 30th 2022, 23:59\n* Fifo Broadcast: November 25th 2022, 23:59\n* Lattice Agreement: December 18th 2022, 23:59\n\n### Submissions\nSubmit your deliverable by uploading it to [this](https://cs451-submissions.epfl.ch:8083) website. Use EPFL’s VPN if you cannot access the submission website.\n\nThe website stores the submission, tests it and then provides with feedback.\nWe advise you to submit regularly, in order to avoid “silly” mistakes (e.g., hardcoding the OUTPUT path).\nDo not use the website to develop (e.g., submit 100 times a day) your project!\n\n**These deadlines mentioned above are definitive. The website does not accept new submissions past the specified deadline.**\n\n**We do not accept submissions over email. Submissions sent over email will not be considered.**\n\nStudents registered to ISA-Academia and/or Moodle will receive by email a passphrase to access the website.\nRead more about how to upload your deliverable to the submission website [here](https://docs.google.com/document/d/1Ai3tQeaTLD0p_2HrVTlONOUskoEExj1HdVOlfIbHdXQ).\n\nThe website runs a simple test to evaluate your submission. Further tests will be ran after the submission deadline.\n\n**Only submissions that pass the website test will be graded.**\n\nIf your submission passes the initial validation, we will evaluate it based on two criteria: correctness and performance. We prioritize correctness: a correct implementation (i.e., that passes all the test cases) will receive (at least) a score of 4-out-of-6. The rest 2-out-of-6 is given based on the perfomance of your implementation compared to the perfomance of the implemantions submitted by your colleagues. The fastest correct implementation will receive a perfect score (6). Incorrect implementations receive a score below 4, depending on the number of tests they fail to pass.\n\n# FAQ\n**1. Can I use multi-threading?**\n\nYes! However, only spawn threads (don't spawn child ​processes​) from your process.\nC11/C++17 and Java support threads natively\n\n**2. Can I put multiple messages in the same packet?**\n\nYes, but we limit the number of messages per same packet to 8. Moreover, you should not use the fact that the payloads are sequential integers nor that the total number of messages is known in advance. For example, your code should work correctly if the payload is some arbitrary text.\n\n**3. Can I compress the messages?**\n\nYes. This is an implementation detail that is up to you.\n\n**4. I implemented the whole project but it does not work correctly (or does not compile). Will I get some points for the implementation?**\n\nNo. Submissions that fail to compile will NOT be considered for grading. Similarly, submissions that fail to produce any output files or produce faulty output files (e.g., empty files) will NOT be graded.\n\n**5. Which performance should I aim for? How many messages per second?**\n\nYou should aim for maximum performance. You can assume that the number of messages will not be more than MAX_INT, i.e., each process will not broadcast more than 2147483647 messages. Also, you can assume that the broadcasting processes will be no more than 128. We know that there are always hardware limits so do not worry too much about this issue. These limits are given to help you with the message structure (e.g., 1 byte is enough to encode the process identifier).\n\n**6. Will there be separate performance rankings for C/C++ and Java?**\n\nYes. C/C++ and Java will be graded separately since the performance may be drastically different. It is up to you to choose the language you are the most comfortable with. We will calibrate the performance of both languages.\n\n**7. How can I introduce delay/loss/reordering in the network?**\n\nFor the purposes of this project all processes execute on the same machine and use the loopback interface.\nYou can easily use [TC](https://man7.org/linux/man-pages/man8/tc.8.html) to change the characteristics of this interface and introduce the desired delay/loss/reordering.\nWe provide the `tools/tc.py` script to simplify the process, however we urge you to consider changing the parameters inside this script to gain confidence in the correctness of your implementation.\nRun this script before starting the processes and keep it running for the duration of the execution.\n\n**8. How can I validate my output?**\n\nIt is your responsibility to ensure that your implementation is correct.\nHowever, we provide a sample validation script for the FIFO broacast (`tools/validate_fifo.py`). This script uses the output files generated by the processes after they terminate their execution.\n\n**9. Is it ok that the processes terminate before they are able to deliver all the messages?**\n\nYes, as soon as you receive a SIGTERM signal, you need to terminate the process and start writing to the logs. You may not have delivered all the messages by that time which is ok. You should only deliver the message that you can deliver. i.e., that does not violate FIFO and URB. If instead you do, while you are not allowed to, you may be violating correctness.\n\n**10. Which files can I modify in the template?**\n\nIn general, you can add whatever you want to ANY file in the template that is NOT marked with DO NOT EDIT. Also, you are NOT allowed to change the function signatures nor the file names. Other than that (like adding a parser, adding some code in the main, create new classes, adding new functions, adding constants, ...etc.) is allowed.\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmatteoldani%2Fda-project","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmatteoldani%2Fda-project","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmatteoldani%2Fda-project/lists"}