|
|
## C/C++
|
|
|
## Index
|
|
|
|
|
|
**TODO**
|
|
|
* [Python API](#python)
|
|
|
* [C/C++](#cc++)
|
|
|
|
|
|
## Python
|
|
|
<a name="python"></a>
|
|
|
|
|
|
First, import prrt as:
|
|
|
For a minimal working server/client, please checkout the [README.md](https://git.nt.uni-saarland.de/LARN/PRRT/blob/master/README.md).
|
|
|
|
|
|
### Socket Creation and Binding
|
|
|
```python
|
|
|
import prrt
|
|
|
s = prrt.PrrtSocket(address=("0.0.0.0", 5000))
|
|
|
```
|
|
|
|
|
|
Open a socket as a receiver:
|
|
|
The previous code import the `prrt` module, creates a PRRT socket, and binds it to all interfaces on UDP port 5000.
|
|
|
|
|
|
You can optionally specify a `target_delay` (in seconds), which is used by PRRT to execute the hybrid error correction (HEC) and expire packets that take too long to reach the receiver. Depending on the `receive` calls you are using, data is delivered to the application ASAP or only when the `target_delay` has passed. The following socket uses a target delay of 50ms:
|
|
|
|
|
|
```python
|
|
|
r = prrt.PrrtSocket(port=5000, isSender=False)
|
|
|
s = prrt.PrrtSocket(address=("0.0.0.0", 5000),
|
|
|
target_delay=0.05)
|
|
|
```
|
|
|
|
|
|
As the PRRT stack uses multiple threads to separate the transmission and reception of data as well as feedback pcakets, threads might be migrated between cores by the Linux kernel. This is avoided by the the following socket that uses threadpinning:
|
|
|
```python
|
|
|
s = prrt.PrrtSocket(address=("0.0.0.0", 5000),
|
|
|
thread_pinning=True)
|
|
|
```
|
|
|
|
|
|
Open a socket as a sender:
|
|
|
|
|
|
### Sending Side
|
|
|
First, you have to specify the peer address using the `connect()` method:
|
|
|
```python
|
|
|
s = prrt.PrrtSocket(port=6000, isSender=True)
|
|
|
s = prrt.PrrtSocket(address=("0.0.0.0", 6000))
|
|
|
s.connect("127.0.0.1", 5000)
|
|
|
```
|
|
|
In contrast to transport protocols such as TCP, this operation does not send out packets. Afterwards, data can be send to the socket using:
|
|
|
|
|
|
```python
|
|
|
data = "And now for something completely different."
|
|
|
s.send(data.encode("utf8"))
|
|
|
```
|
|
|
|
|
|
The coding parameters for the HEC can be set by creating a `PrrtCodingConfiguration(n, k, n_cycle)` object and assigning it to the socket:
|
|
|
|
|
|
```python
|
|
|
config = PrrtCodingConfiguration(7, 4, [3])
|
|
|
s.coding_configuration = config
|
|
|
```
|
|
|
|
|
|
This configures the coding to accumulate 4 data packets (`k`), compute 3 additional (`n-k`) and sends these as soon as the encoding has finished. Note that the data packets are sent out immediately by the stack and by the time the last packet is sent, the coded redundancy is transmitted.
|
|
|
|
|
|
There are numerous channel parameters that PRRT measures passively and which can be queried from the socket:
|
|
|
|
|
|
* `datarate_fwd`: The estimated delivery rate on the path from the sender to the receiver. The delivery estimation follows the [IETF Draft](https://tools.ietf.org/html/draft-cheng-iccrg-delivery-rate-estimation-00) by Google.
|
|
|
* `datarate_back`: The estimated delivery rate on the path from receiver to the sender, which was estimated by the sender and communicated within the recently received packets.
|
|
|
* `latency_fwd`: The estimated latency on the path from sender to the receiver. The latency is estimated with a similar approach as NTP uses, so the stamps at the receiver side are part of the feedback packets.
|
|
|
* `lossrate_fwd`: The estimated packet loss rate on the path from sender to the receiver. The receiver keeps a window of recently received packets, computes the number of losses as well as the length of gaps and burst, and communicates this information to the sender via feedback packets.
|
|
|
|
|
|
### Receiving Side
|
|
|
The data can be received on the receiver by:
|
|
|
|
|
|
```python
|
|
|
data = r.recv()
|
|
|
print(data.decode("utf8"))
|
|
|
```
|
|
|
|
|
|
Note that there are different [modes for reception](receive-modes) which take e.g. the target delay into account and differ in their blocking behavior. |
|
|
\ No newline at end of file |
|
|
Note that there are different [modes for reception](receive-modes) which take e.g. the target delay into account and differ in their blocking behavior.
|
|
|
|
|
|
## C/C++
|
|
|
<a name="cc++"></a>
|
|
|
The API documentation for C/C++ is not yet available, so please consider the `socket.h` header file for more information. |