dwrtc / sa Goto Github PK

0.0 0.0 0.0 0 B

sa's Introduction

DWRTC - Distributed WebRTC Signalling

DWRTC extends WebRTC with a decentralized connection setup (signaling). Users connect to different nodes on the Internet. These nodes are connected via a P2P network which stores the routing information. The connection setup messages are routed through this network. The WebRTC connection can then be used to send data, audio and video directly from web browser to web browser.

As a proof of concept, the project also includes a video call application using DWRTC to establish calls to a partner.

Project Page: dwrtc.net

WebSocket API documentation: docs.dwrtc.net/dwrtc/ch.hsr.dsl.dwrtc.websocket

Full Kdoc documentation: docs.dwrtc.net

JS documentation: src/main/resources/web/README.md

Run

To run DWRTC the easiest way is to use the Docker container:

docker run dwrtc/dwrtc

Use the environment variables mentioned in the options section to configure DWRTC.

Options

Options are loaded using Konfig. The priorities are:

Command Line Properties overrides
Environment Variables overrides
Property file defaults.properties

Use the "dot"-syntax (http.port) for command line and property file, and "underscore"-syntax for environment variables (HTTP_PORT).

The options are:

Peer Port (Int): peer.port/PEER_PORT: port the TomP2P peer runs on
Webserver IP (String): http.ip/HTTP_IP: the IP the web server binds to (e.g. "127.0.0.1", "localhost", "0.0.0.0")
Webserver Port (Int): http.port/HTTP_PORT: the port the web server binds to
Bootstrap Peer (comma-separated list of HOST:PORT pairs): bootstrap.peer/BOOTSTRAP_PEER the list of peers to bootstrap to (e.g. "1.1.1.1:4000,2.2.2.2:3000")

Local Usage

$ docker-compose up -d
$ docker-compose ps

    Name               Command           State                        Ports
-------------------------------------------------------------------------------------------------
dwrtc_node1_1   java -jar /app/app.jar   Up      0.0.0.0:PORT1->7000/tcp, 0.0.0.0:32770->7532/tcp
dwrtc_node2_1   java -jar /app/app.jar   Up      0.0.0.0:PORT2->7000/tcp, 0.0.0.0:32768->7532/tcp

Connect to localhost:PORT1 for node1 and localhost:PORT2 for node2 via a web browser. You can also connect to the TomP2P ports (32768/32770 in this case) to bootstrap any instance running outside of this network.

sa's People

Contributors

Watchers

sa's Issues

Project Plan

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

Find someone to correct our thesis

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

Fulfill formal requirements

Document deployment

Deploy coturn

Check cite style

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

Persönliche Reflektion

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

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.

Title Page

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

Draw architecture

Find Web framework

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

API Doc

Very basic. We can basically specify our message formats.

Document TURN ping state

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

Pre-commit hooks for thesis doc

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

Populate project page

Put on a basic design and some content

Populate project page

Set up project page

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

Write project description

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!

TURN server interface

What interface should a TURN server present to a browser?

This is needed if we develop our own TURN server

Fix Sonarcube analysis

Implement class structure

Check distribution methods

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

Add coverage to SonarCloud

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

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

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

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

Set up project

Set up a project incl. dependencies

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)

Poster

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

Document code style

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 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:

Check SimplePeer

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

Class diagram/Layers

Abgabe Checkliste

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

Fü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. Fü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.
Für publizierbare Arbeiten: Ein PDF einer publizierbaren Version der Arbeit, ohne die
persönlichen Berichte, Sitzungsprotokolle, Vereinbarungen über Urheber- und Nutzungsrechte, Adress-Informationen. Aus Datenschutzgründen ist darauf zu achten, dass keine persönlichen Daten von Industriepartner und Experten (Email-Adressen, Telefonnummern) enthalten sind.
Formulare (z.B. Eigenständigkeitserklärung, Nutzungsrechte, ...)

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.

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

Write disadvantages

Student project - no security or privacy concerns

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.

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

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

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