Skip to content

gciatto/sd-project-proposals

BranchesTags

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

2 Commits
README.md
README.md
 
 

Repository files navigation

Proposed Projects for the Distributed Systems course

Giovanni Ciatto, Stefano Mariani, Andrea Omicini

Overview

Proposed projects are divided into the following main categories:

Tuple Based coordination, where students may contribute in several ways to our software artifacts concerning the tuple based coordination, i.e.:

TuSoW: the same LINDA implementation you used during the Lab lessons

TuCSoN: another legacy implementation of LINDA, which is and has been the basis for several research works in our team. In particular, it supports not only tuple spaces but also tuple centres

  • You can read more about TuCSoN and the tuple centre notion by looking for the many papers mentioning them among the ones published by prof. Omicini

    • log in with your @studio.unibo.it credentials on the Apice portal, in order to be able to download and read our papers

  • Or you may look for the many theses on these subjects available on AMS Tesi

ReSpecT: a language aimed at programming tuple centres in order to govern the interaction space

Logic Programming as a Service (LPaaS), where students may contribute in several ways to our software artifacts concerning the LPaaS ecosystem

Blockchain, where students may contribute in several ways in order to improve their (and our) understanding of the Blockchain model and technology

[Byzantine] Fault Tolerance ([B]FT) & State Machine Replication (SMR), where students may contribute in several ways in order to improve our understanding of the BFT & SMR models and technologies

Language and frameworks for Distributed Systems (DS) or Agent Oriented Programming (AOP), where students may contribute in several ways in order to create or improve new languages or toolkits within the scopes of DS, Coordination, and AOP

  • Projects in this category may rely on one or more of the following frameworks:

Simulation: where students may contribute by creating novel incarnations for the Alchemist simulator

DevOps: where students can practice with real-world DevOps technologies such as Docker and Kubernetes

Lesson Production: where students can help designing and writing lessons for the future editions of the course

Technology Know-How: where students may contribute exploring the functioning (and possibly the internal structure) of one or more real-world technologies

The "Tuple Based coordination" category

This category comprehends the following projects

  1. Designing and implementing a RBAC access control feature for TuSoW, to be enforced by means of an authentication and authorization layer to be injected into the current model and implementation

    • The implementation should rely on standard technologies such as SSO or OAuth

  2. Designing and implementing a variant of TuSoW supporting the replication of tuple spaces on several distributed machines

    • This may also mean creating/looking for a Storage Layer for TuSoW to be injected into the current model & implementation

  3. Designing and implementing a variant of TuSoW supporting the sharding of tuple spaces on several distributed machines

    • This may also mean creating/looking for a Storage Layer for TuSoW to be injected into the current model & implementation

  1. Designing and implementing a server-side interface for LINDA (or TuSoW core) based on Javalin + simple project, max 1 person

  2. Designing and implementing a client-side interface for TuSoW supporting two or more of the follwing platforms:

    1. JVM (Java, Kotlin, Scala, etc)
    2. .NET (C#, F#, VbNET <-- please don't)
    3. JavaScript
    4. Python
    5. < any language you like >

    (notice that these are actually different projects)

    Teams composed by more than 1 people may be asked to support more than 1 plaftorms

  3. Designing and implementing an observability module for TuSoW enabling the implementation of a Web-based monitoring (graphical) interface, targetting: - JavaFX - some web GUI

    (notice that this activity may require some modification to the current implementation of TuSoW service)

  4. Designing and implementing an Android-based porting of TuSoW supporting replication of tuple spaces among several devices, possibly interconnected by means of Bluetooth or Wifi-Direct - there are some ongoing activities on this track, yet if you are interested let's talk about it

  5. Designing and implementing an Android-based porting of TuSoW supporting federation of tuple spaces à la LIME among several devices, possibly interconnected by means of Bluetooth or Wifi-Direct - there are some ongoing activities on this track, yet if you are interested let's talk about it

  6. Fix the "phantom in" problem by supporting primitives cancellation from the client side in TuSoW

  7. Experiment with novel Coordination languages in TuSoW, e.g.

    • JSON|YAML and JsonPAth
    • XML and XPath
    • whatever you like

The "LPaaS" category

  1. Completely rewriting the current Java EE based source code using Javalin, Vert.x or some other lightweight, micro-service oriented library or framework. The novel implementation should include at least:

    • an improved modularization of the Knowledge-Base Layer
    • a suite of fine grained unit tests

    Notice that the novel implementation should anyway adhere to the LPaaS Swagger Specification

  2. Designing and implementing an observability module for LPaaS enabling the implementation of a Web-based graphical interface

  3. Designing and implementing a client-side interface for LPaaS supporting one of the follwing platforms:

    1. JVM
    2. .NET (C#, F#, VbNET <-- please don't)
    3. Python

    (notice that these are actually different projects)

  4. Design a novel 2P-Kt Playground capable of switching among in-browser or LPaaS-based computing mode

Furthermore, we are also interested in students designing and developing an unbiased and non-trivial usage scenario for LPaaS. You can propose some.

The "Blockchain" category

No specific project here, but just some ideas you can use as a starting point when proposing a project of yours.

We have four different rearch interestes concerning blockchains:

The "BFT & SMR" category

Projects in this category follow a common pattern:

  1. Students choose a consensus algorithm from the list below,
  2. They study the corresponding paper / reference and try to understand the consensus algorithm's functioning
  3. They create a proof of concept implementation it using a technology of choice
  4. They test the consensus algorithm's robustness agains crash and byzantine faults

There is an implic step hidden into the procedure above: consensus algorithms are usually aimed at implementing some sort of SMR system (e.g. a replicated DB). Even if the goal of a project in this category is to study & implement a consensus algorithm, students may need to actually use it in order to test it. To do so they will have to create a simple SMR system, like, e.g. a replicated Key-Value store supporting at least two operations: put and get.

Students may choose any of the following consensus algorithms:

Overviews and surveys are available in order to perform a quick evaluation and comparison among the protocols above:

Finally, the following readings may of interest for who is interest in understanding the many impossiblity results affecting the distributed consensus:

The "Language & frameworks for DS or AOP" category

  1. Design and implement a plugin for Swagger's Codegen aimed at generating server stubs starting from a Swagger specification file.

    - Vert.X target
- Javalin target
- Play target
- choose your own target

  2. Design and implement a Domain Specific Language aimed at easing the development of JADE-like agents

    • It is possible to use any one among the following DSL engineering technologies: Xtext, MPS, ANTLR

  3. Design a Kotlin|Scala DSL for Jade-like Agents

The "Simulation" category

  1. Design and implement an Alchemist incarnation aimed at simulating situated tuple spaces and, possibly, the Spatial Tuples model

  2. Design and implement an Alchemist incarnation aimed at simulating situated tuple centres

  3. Design and implement an Alchemist incarnation aimed at simulating JADE-like agents

DevOps category

Projects in this category follow a common pattern:

  1. Students choose a technology from the list below aimed at setting up clusters of interconnected machines,

  2. They must study it and understand its purpose & functioning, possibly looking for scientific paper describing it

  3. They must figure out and document how to set up a single-machine cluster

  4. They must figure out and document how to set up a multi-machine cluster

  5. They must figure out and document how to set up access control and usage quotas

  6. They must figure out and document how to submit computational jobs to the cluster

  7. They must figure out and document how to submit storage-intensive jobs to the cluster

  8. They must figure out and document how to deploy web-services or super-servers on the cluster

Avalilable technologies:

Lesson Production category

  1. Design a lab lesson about replication of Linda tuple spaces

    • master-slave
    • crash-tolerant
    • BFT

  2. Design a lab lesson about federation of Linda tuple spaces

  3. Design a lab lesson about sharding of Linda tuple spaces

  4. Design a lab lesson non-blocking IO

  5. Propose your own lab lesson to be designed

The "Technology Know-How" category

Projects in this category follow a common pattern:

  1. Students choose a technology from the list below,

  2. They must study it and understand its purpose & functioning, possibly looking for scientific paper describing it

  3. They must undestand how the technology setup works and it is deployed in a real-world scenario

    • Docker Swarm may be useful in some cases
    • Such information must be included into the final report

  4. They must test it, possibly creating some non-trivial testbed scenario

    • It is not sufficient to just copy & past examples from the Web
    • The test bed scenario must be propertly designed in order to reveal the technology pros and cons

  5. They must stress it, possibly creating some testbed pushing the technology out of its comfort zone

  6. They must produce a detailed report describing

    • the technology,
    • its reference model (if any),
    • the assumption it relies upon,
    • the tests performed and their rationale,
    • the problems it solves
    • the problems it DOES NOT solve
    • etc

Avalilable technologies:

Notice that projects in this category are quite different. Here, we only expect students to produce some non-trivial testbed + some other code examples as software artifacts. The real goal of this sort of projects is to condensate into some useful and written form the knowledge related to a particular technology. Because of this, the final repor must be very detailed and properly written, without assuming the reader have any prior knowledge concerning the technology presented into the report. For this reason final report have no page limitation in this category.

Notice that technicalities are not the only thing that matters. This is why we ask you to reason about a technology, and think about:

  • why should people use it?
  • why people should NOT use it?
  • does it scale?
  • etc.

As a rule of thumb consider the following statement:

if your report does not present any problem of the target technology, you are probably missing something

About

No description, website, or topics provided.

Resources

Readme
Activity

Stars

0 stars

Watchers

1 watching

Forks

0 forks
Report repository

Releases

No releases published

Packages

No packages published