Public Repository

Last pushed: 2 years ago
Short Description
This repo contains images for NDN-RTC v1.4.4 Ubuntu Headless Application
Full Description

Ubuntu headless application

Ubuntu headless application - is a console app that is built agains NDN-RTC and allows to fetch (audio/video) or publish (video) streams over NDN.

Quick how-to

In order to start application, one have to write or modify an existing (recommended) configuration file. A sample configuration file can be found in the repo. Test configuration files can be found in /root/headless/config folder inside the image.

Headless application takes several command-line arguments:

  • -c - config file (full path)
  • -s - signing identity name
  • -i - application instance name
  • -p - config policy file (full path)
  • -t - run duration (in seconds)
  • -v - verbose output to the console

For example, one would use this command to start application for 30 seconds:

$ ndnrtc-client -c config.cfg -s /ndn/edu/ucla/remap/peter -i client1 -p policy.conf -t 30

Connecting two containers (same host machine)

In order to setup one container as a producer and the other one as a consumer, one should create a docker subnet and connect both containers to it. Each container will run a headless client - one as a producer, the other one as a consumer.

  1. First, create folders in the host OS which will be mounted inside containers and where clients will save log files:

    $ mkdir -p client0/logs client1/logs
  2. Create Docker network:

    $ docker network create subnet
  3. Start NFD on both containers and register a prefix from consumer (client1) to producer (client0):

    $ docker run --name client0 -d --net subnet -v $(pwd)/client0:/root/headless/host peetonn/docker-ndnrtc-ubuntu14.04 nfd
    $ docker run --name client1 -d --net subnet -v $(pwd)/client1:/root/headless/host peetonn/docker-ndnrtc-ubuntu14.04 nfd
    $ docker exec client1 nfdc register / udp://client0
  4. In separate terminal windows, run these two commands:

    $ docker exec client0 ndnrtc-client -c /root/headless/config/test-producer640.cfg -s /ndn/edu/ucla/%40GUEST/ -p /root/headless/config/rule.conf -i client0 -t 60
    $ docker exec client1 ndnrtc-client -c /root/headless/config/test-consumer.cfg -s /ndn/edu/ucla/%40GUEST/ -p /root/headless/config/rule.conf -t 30

Producer will run for 60 seconds; consumer will run for 30 seconds (this can be changed at will by using -t parameter). Image comes with a test raw video frames (~60 frames, 640x480); playback will be looped.

After a run, log files can be found in client0/logs and client1/logs for producer and consumer accordingly. Received raw video will be stored in client1 folder.

If one does not need to save received video in a file, a corresponding option in configuration file (click to be redirected to the repo) should be removed.

Check received video

In order to check received video, one can run ffmpeg to encode raw video into mp4 and play it using any video player:

$ ffmpeg -f rawvideo -vcodec rawvideo -s 640x480 -r 27 -pix_fmt argb -i client1/client0-video-0-480x640.argb -c:v libx264 -preset ultrafast -qp 0 client0.mp4

Signing identity

Signing identity is used to generate application instance identity and instance certificate which will be used to sign all published data. If signing identity does not exist in default keychain, application will automatically create one. In order for consumer to verify data, it should be able to 1) fetch instance certificate and 2) check signing identity certificate. By default, application publishes its' instance certificate, but don't publish signing identity certificate as it belongs to outer namespace and is not application's responsibility. Consequently, user should make sure that signing identity certificate is accessible for the consumer application. One way to do it - is to specify trust policy in configuration file (which is passed as an argument -p) where instance identity is checked. Default policy configuration file inside the image (located at /root/headless/config/rule.conf) looks like follows:

        id "Validation Rule"
        for data
            type hierarchical
            sig-type rsa-sha256
        type file
        file-name "/root/headless/config/anchor.cert"

As can be seen, it depends on the trust anchor anchor.cert. By default, this file is a certificate for /ndn/edu/ucla/%40GUEST/ identity. This identity is used in the following test example.

However, If you'd like to use your own identity, you need to make sure 1) to properly generate signing identity
and 2) make signing identity accessible for the consumer. As an example, let's say you want to publish under /a/b/c/d identity:

  1. First, create identity on the producer docker instance:

    $ docker exec client0 ndnsec-keygen /a/b/c/d | ndnsec-install-cert -
  2. Dump certificate into a file on your local machine:

    $ docker exec client0 ndnsec cert-dump -i /a/b/c/d > my.cert
  3. Copy my.cert over to the consumer docker instance (via shared volumes, for example).

  4. Update rule.conf to point to the copied certificate file.
Docker Pull Command