dwrtc/sa

sa's Issues

Investigate: Distributed STUN/TURN servers

Could we do something similar like DWRTC with STUN/TURN servers?

Abstract + Management Summary

Write requirements

• Use Cases
• Non-functional
  • Check EngProj doc. There's a cited standard way of doing these (what sections there are)

Connection animation

See https://github.com/fjl/p2p-drafts/blob/master/devcon3.pdf

Find Web framework

@thde found these that are written in Kotlin (if we use Kotlin):

• https://github.com/ktorio/ktor
• https://github.com/tipsy/javalin
• https://github.com/Tinder/Scarlet

Check cite style

Which style should we use when citing? (is [12] ok?)

Proof of Concept

This works already

• Server 1 => puts something in DHT
• Server 2 => reads something from DHT

We can add

• Peer 1 => connects via Websocket to Server 1 and sends message (that

The rest will work as-is

If we want to go one step further

• Peer 2 => connects via Websocket to Server 1 and gets the message (pushed)

Investigate new idea

• Set up a few servers that make up a DHT
• Each peer connects to one of these servers
  • A peer can also download the server software and become part of the DHT, independently
• The server handles new peers, and when a peer wants to connect to another peer, would facilitate the exchange of connection details, and prepare both peers that they're going to be contacted directly

Persönliche Reflektion

Persönliche Berichte einschliesslich (selbst-)kritische Reflexion der Studierenden zu ihren Erfahrungen bei der Arbeit.

Different project proposal

We would rather use this architecture:

Basically, we write a P2P API that's responsible for exchanging connection details between peers. It would consist of an API client, running in a browser, and an API server, running in whatever language would suit. They would communicate over HTTP. This would all run on each client!

The API server would have a DHT library at its disposal, which is joined in a DHT with other P2P servers. The API client would talk to the browser's built in WebRTC component.

Whenever the API client requests a peer's connection details, the server would in turn ask the DHT library. The client then hands this information over to the WebRTC component. The WebRTC component then opens a direct connection to the peer's WebRTC component.

Document TURN ping state

Document that turn ping is used, but not the algorithm where all peers are asked for their ping measurements

Poster

https://wiki.hsr.ch/FarhadMehta/wiki.cgi?ProjectInformation#18

Glossary

Fix Sonarcube analysis

TURN server interface

What interface should a TURN server present to a browser?

This is needed if we develop our own TURN server

Set up project

Set up a project incl. dependencies

Search for Turn Servers for Deployment

https://github.com/gortc/gortcd
https://github.com/coturn/coturn
https://github.com/jselbie/stunserver

I'd go for https://github.com/coturn/coturn

Document deployment

Test

Find someone to correct our thesis

Prio 1: English teacher
Prio 2: someone we personally know

API Doc

Very basic. We can basically specify our message formats.

Deploy coturn

Pre-commit hooks for thesis doc

Make sure we write some words that have disputable spelling always the same (e.g. signaling vs signalling)

Check requirements

Sort through the documents and check what we need to do

Keerthi mentioned that Thomas is already doing this, as part of what he requires from our side.

Document code style

Check distribution methods

Can we use Flatpak, AppImage (...) for distributing our (probably Java) app?

Document quality measures

Unit Tests, Code Reviews, Code Style

I think it's a plus that we found and reported two issues in the open source world:

• feross/simple-peer#366
• javalin/javalin#423
• traefik/traefik#4159

Fulfill formal requirements

Write project description

Amend TURN section: Tom's ideas

Our current main point against distributed TURN servers is performance. Tom suggested a procedure where we find the nearest TURN servers to both peers (or between them, etc.)

After figuring out #37, amend the section in the SA document with our findings.

Mention how we would design certain applications

• Group Chat: have a special coordinator/host that tells everyone who they must send the messages to too.

Abgabe Checkliste

• Update all draw.io drawings (upload, export as PDF using Crop + Selection Only, download)
• "Remove intermediate files" before building PDF

Für die Publikation der Arbeit auf eprints.hsr.ch: Folder mit:

• Zustimmung zur Publikation der Arbeit, unterschrieben von den Studierenden. Oder Information, ob einer oder beide der Studierenden die Arbeit, bzw. ihren Namen nicht publiziert haben wollen. Für vertrauliche Arbeiten: Aufgabenstellung aus der ersichtlich wird, dass die Arbeit vertraulich ist.
• Ein Plain-Text Abstract der Arbeit, welches auf eprints.hsr.ch publiziert wird.
• Für publizierbare Arbeiten: Ein PDF einer publizierbaren Version der Arbeit, ohne die
  persönlichen Berichte, Sitzungsprotokolle, Vereinbarungen über Urheber- und Nutzungsrechte, Adress-Informationen. Aus Datenschutzgründen ist darauf zu achten, dass keine persönlichen Daten von Industriepartner und Experten (Email-Adressen, Telefonnummern) enthalten sind.
• Formulare (z.B. Eigenständigkeitserklärung, Nutzungsrechte, ...)

Figure out how to add Kdoc as an attachment

We can generate markdown but that just leaves us with pages that don't fit nicely together.

Check SimplePeer

Does it help us?
Does it need a specific server interface for signalling or is that up to you?

Add coverage to SonarCloud

Add a coverage plugin to Gradle and make sure SonarCloud finds it

Title Page

Create it in Word, make sure the font is the same as in LaTeX. Then simply \includepdf

Draw architecture

Populate project page

Put on a basic design and some content

Check codecs

Are these codecs suitable for a P2P Skype on a laptop?

Note: we've not yet defined if it's just about audio, or video too.

• OPUS
• AV1

Class diagram/Layers

Populate project page

Write up what we've done so far

• Start with idea of Java gui and Codecs etc
• not good, too much effort
• use webrtc, but most of the things are done for you
• there's a signaling channel that you have to implement yourself
• do that

Figure out a way for E2E testing (manual)

How can we start two of our servers so that they run on the same machine? These would simulate two servers.

• This should scale, it should support more than two servers

Familiarize with TomP2P

Make ourselves familiar with TomP2P

We discussed setting up a DHT between all clients. When a client goes online, it PUTs its current connection details with its ID as the key. When you want to reach this client, you could GET the connection details from the DHT and connect directly.

But, this is all very open for discussion!

Implement class structure

Write disadvantages

Student project - no security or privacy concerns

Project Plan

Write up a project plan, maybe similar to the one used in EngProj (including risks, organisation, time tracking, methods used (agile, iterative?), ...)

Set up project page

Set up a website, where we could distribute documents. Probably use Github Pages?

Does WebRTC check latency to its STUN and Turn servers?

If we tell WebRTC what STUN and TURN servers it can use, does it automatically check the latency to those?
If not, how can we influence this decision? (e.g. a weighted list)

Document TURN server latency agreement

Implement algorithm as defined. Probably dependent on #65