WARNING -- THIS SOFTWARE IS NO LONGER MAINTAINED AND SHOULD BE CONSIDERED INSECURE. See this page for information about other open source, free and paid NMOS products.
See
A web based application for connecting multicast RTP Senders and Receivers using AMWA NMOS IS-04 and IS-05. This is a basic tool, intended to provide a reference example for implementors and to aid with testing.
The following instructions have been tested on Ubuntu 16.04, but may work for other operating systems.
$ git clone https://github.com/bbc/nmos-web-router.git
$ cd nmos-web-router
$ sudo ./install.sh
$ yarn install
$ yarn start
This will run the application in development mode, launching a web browser automatically.
Note: If you see senders such as 'BBC One (HD)' then the application is running with stub data and has been unable to find an active IS-04 registry.
npm start # starts the dev service
npm run build # creates a build folder and builds everything needed
npm run serve # runs build and then starts serving
npm run lint # lints the javascript and styles
npm ci # runs lint and jest, should be run on CI
npm test # runs lint and jest and then starts watching with jest (it is amazing)
npm test -- --updateSnapshot # runs lint and jest and updates all the snapshots
npm test:once # will run the tests once only
npm run nmos # starts the nmos server
npm run mdnsbridge # starts local mdnsbridge, see ./scripts/mdnsbridge-local.js to see what it returnsThis project uses flux, using react and redux as well as the react-router
each folder maps to a route
each route has a container
each container can have: a reducer, a dispatcher and multiple components
You can use CSSNext in any css file. It is good to keep the css file next to the thing it is styling and them import the style with import './style-file.css'
The other thing to note is the route is added a class to the main containers. Styling based on the route makes things a lot easier, then you do not need to write JavaScript to hide things when the route changes for example
There is a file src/drc.js
This is what allows us to have a configuration approach to Redux and the React Router. Here is more in-depth information README
You can find all Gel things in the src/gel-react README
You can find all IPS NMOS API things in the src/ips-nmos-api README
If you aren't running scripts/dev.sh then you can run
npm run nmos
If you want to add a delay
npm run nmos -- --delay=500
But if have a running you can simply run
npm run nmos -- --connect
This should connect to the docker container as well after using scritps/dev.sh
You can then get access this from in 2 ways
Either using http://localhost:3000/?url=http://localhost:6589
or you will need to start the mdnsbridge task as such
npm run mdnsbridge
If you have run scripts/dev.sh then you will not need to do this
You can configure the ports for everything except mdnsbridge, it is 12345
npm run nmos -- --ws-port=3001 --http-port=3002 --repl-port=3003
read the README for more information on this
You can also change the priority using priority=888 for example
If you are using the local stub data then priority=888 will point to the live data (might be brittle if the ip addresses change, if this happens then look in scripts/mdnsbridge-local.js)
If you are using mdnsbridge, because everything is now on port 80 you can add mdnsbridge_port=12345 as a query param e.g. http://localhost:3000/?mdnsbridge_port=12345 and it will set the port for you, otherwise it will default to port 80
Uses Jest for testing. Just write a file in src with the extension *.spec.js or *.test.js
Things which are being tested
- components with complex logic, i.e. if a component does more than just render DOM it should be tested, it may be as simple as prop validation. Otherwise it can be tested by simply looking at the code and having the linting pass
- dispatchers with complex logic unless it is http requests. HTTP requests should be done using some kind of integration (see below)
- reducers that return something other than static JSON
There are currently no screenshot or integration tests currently, still MVP and unstable. These tests would be too brittle until post MVP when the project has become more defined
Screenshot tests would be used to check CSS and so should be limited where possible, not to check DOM structure which can be better tested with Jest snapshots
Integration test would start a local NMOS API instance and then check that the data is being loaded in correctly and verified using a single snapshot. This is to check that the data is being processed as expected, not to check DOM structure nor to test CSS
./scripts/build.sh # creates the docker image and also copies the build file for deploying, jenkins doesn't seem to like running this script so just copy it's contents to jenkins and add sudo to everything as a temprory fix
./scripts/dev.sh # starts `npm start` from the container with the container name `ips-web-dev` it also starts the nmos and mdnsbridge tasks
./scripts/start.sh # starts `npm serve` from the container with the container name `ips-web-start`Here is the build Job it just runs the build but will fail if the tests fail.
This is just a section to help with language, the code is written using this language, and should be something which everyone can talk in in order to know what is what
Tool used to create routes between senders and receivers
Either a Sender or Receiver
Some kind of connection between a sender and a receiver
Most of the testing is around ./src/web-router/routables and most of the logic should be here
If you run a build locally and then run npm run serve you will need to copy all the files in build to build/ips-web. You can either add this as part of a build job or change the package.json homepage but it seems easier to not bother. It is so similar to npm start that is isn't worth the hassle
There is also a ./processor-generator.js and a ./processor-generator.spec.js which will generate random processors which is to be used for testing the new configurator. You can find more docs at ./processor.md