README.develop

DEVELOPER NOTES:


Latest thoughts (Mon Nov 5 2018):

- The hardest part of the problem is contest account management.  We
  handle this difficult problem by avoiding it, with the introduction of a
  single scenario web server.  This scenario web server only runs while
  the scenario is active.  The account management is handled by passing
  out URLs with a query part that has a generated pass-codes.  After the
  scenario is complete the pass-codes will no longer be valid.

- Scenario Web Server - gets around account management on a central web
  server by keeping history and pass-codes of only the current scenario.

- Launch a node web server for each "Scenario", when the person with
  the server computer account is the master of the scenario.

- The URLs of the web server will have a pass-codes in them,
  which passcode depends on what team user is in.
     * We can have a special super-user passcode that
       gives them more control.


- (FUTURE) There may be more than one web server per scenario.
     * This means we need to be able to remove and add controllers on
       the fly, which means we need to have stream start and stop, and
       effect a stream restart capability.

- There will be an authenticated control group for each control parameter.
    * This kind of fine grained authentication may be a pain.  So maybe
      just having one authentication token per controller may be easiest.


- The scenario controller is a node web server.
- In the future a master web server can launch the scenario controller web
  servers, for now we require that the person launching the scenario
  controller have an account on the computer that runs it.

- There is any number of Controllers in the stream that connected to the
  scenario controller.

     * This Controller has a controller group that is authenticated
       and allowed to use it, that is set and get parameters.


- In the future we can make a Master web server that spawns "Scenario Web
  Servers".  Such a master web server has to have account management,
  where as the Scenario Web Servers will only keep a running
  authentication data structure without any data base.  The master web
  server would have an account management system with a data base.


- It would be nice to have a CRTS controller that is a server too, in
  addition to the  CRTS controller client.  Then we could make a more
  interesting shell that would be a client.  It should replace the
  FIFO based shell.




Collection of notes to study:

WebRTC google talk
https://www.youtube.com/watch?v=p2HzZkd2A40

WebRTC getUserMedia Test Page
https://mozilla.github.io/webrtc-landing/gum_test.html

moving Firefox and WebRTC forward
https://blog.mozilla.org/webrtc/

WebRTC - Signaling
https://www.tutorialspoint.com/webrtc/webrtc_signaling.htm

GStreamer WebRTC demos
refers to most of the gstreamer codes.
https://github.com/centricular/gstwebrtc-demos

3D graphing browser javaScript API
https://github.com/almende/vis


C library for encoding, decoding and manipulating JSON data
https://github.com/akheron/jansson



TODO:

We need to get rid of X3DOM.  It does not seem to be maintained well.
Currently we have to use an out-of-date version because all newer versions
do not support elevationGrid.

In it's place we should use the WebGL which is has native support in
the browsers.  Or three.js https://threejs.org/






Classes internal to program crts_radio:


   Thread

         static global thread barrier
         static mainThread


     each Thread

         is a list of FilterModule


  FilterModule

         the private part of CRTSFilter

         container for CRTSFilter

         
         Data flowing from one filter to another there if switches:

            1) if not different thread calls CRTSFilter::input()

            or

            2) or signals cond to thread to call CRTSFilter::input()
                 or blocks and ... if the queue is full



  Stream

         static factory of Stream
         static mutex
         static cond


    each Stream

         atomic bool isRunning (TODO: maybe just volatile)

         is a factory of FilterModule

            load()   - create a FilterModule for a stream
            unload() - delete a FilterModule from a stream

         is a factory of Thread

             createThread()

             destroyThread()



How does GNUradio work:  After reading this I see that we are doing many
of the same things as GNU radio, but we have some things that are much
more efficient than GNU radio, like for example we do not require that all
blocks run in a separate thread, the blocks can share threads any way you
choose.

    https://www.gnuradio.org/blog/buffers/




Tests:



cat /dev/urandom | hexdump  | dd count=100 > xxx1
cat /dev/urandom | hexdump  | dd count=100 > xxx2

while ./crts_radio\
 -l sleepTest\
 -f fileIn [ --file xxx1 ]\
 -f fileIn [ --file xxx2 ]\
 -f sleepTest -f sleepTest\
 -f stdout\
 -t 0 -t 1 -t 3 -t 4\
 -c 0 2 1 3 2 4 3 4\
 > xxxx ;\
 do echo -e "\n\nSuccess\n\n" ;\
 sleep 1 ; done


./crts_radio -l sleepTest\
 -f sourceFeed\
 -f fileIn [ --file xxx1 ]\
 -f fileIn [ --file xxx2 ]\
 -f sleepTest\
 -f sleepTest\
 -f stdout\
 -c 0 1 0 2 1 3 2 4 3 5 4 5\
 -d -e

 # or with a single thread running all
while ./crts_radio -l sleepTest\
 -f sourceFeed\
 -f fileIn [ --file xxx1 ]\
 -f fileIn [ --file xxx2 ]\
 -f sleepTest\
 -f sleepTest\
 -f stdout\
 -c 0 1 0 2 1 3 2 4 3 5 4 5\
  > xxxx ; do \
  echo -e "\n\nSuccess\n\n" ; sleep 1 ; done


 rm xxx*


## Ports

Currently developing on: 
  - Debian GNU/Linux 9.3 (stretch)
  - Debian GNU/Linux 8.10 (jessie)
  - Ubuntu 16.04

## Tests

```
cd interactiveTests
```

and look at and run test programs in that directory.


# for gstreamer-1.14.1 source
libbison-dev
flex
gtk-doc-tools
json-glib-tools
libjson-glib-dev
libnice-dev

http://create3000.de/x_ite/custom-shaders/

# WebRTC
https://web-engineering.info/node/57