Networked Media Open Specifications
HOME DOCS GITHUB INFO... TOOLS... IS-XX... MORE... SEARCH

IS-04 Node API

←Advanced Testing · Index↑

The IS-04-01 test suite includes some complex tests for the interaction between Nodes and network services including DNS-SD and the Registry.

test_01, test_01_01, test_02, test_02_01: Node can discover a suitable network registration service via DNS-SD

These tests check that a Node can correctly discover and interact with an advertised registry.

Dependent on the mode which the testing tool is configured in, either test_01 or test_02 will execute, but never both. When these tests execute note that they run at the same time as test_01_01 or test_02_01 respectively. If your Node is unable to pass test_01_01 it will be unable to pass test_01 until this is fixed. Similarly, if your Node fails to pass test_02_01, it will be unable to pass test_02 until this is fixed.

Testing Method

test_15: Node correctly selects a Registration API based on advertised priorities

This test checks that a Node can fail over between a set of advertised registries when one fails, and that when doing so it always fails over to the next best registry as determined by their priority (‘pri’ TXT record).

It is important to note that Nodes are expected to immediately try the next available registry when they receive an error code such as an HTTP 500 upon heartbeating. This ensures that if they were previously successfully registered, they have the best chance of avoiding having to re-register all of their resources with the next registry in the list. Whilst Nodes are expected to perform exponential backoff to avoid overloading registries, this is only expected to occur once each available registry has been contacted once, indicating a more major error.

Note that this test is executed at the same time as test_16 and test_16_01.

Testing Method

test_16: Node correctly fails over between advertised Registration APIs when one fails

This test checks that a Node can fail over between a set of advertised registries when one fails in a controlled fashion (with a 5xx error code).

Note that this test is executed at the same time as test_15 and test_16_01.

Testing Method

This test uses the same method as test_15, but additionally checks that when switching to a new registry the Node does not attempt to re-register all of its resources.

test_16_01: Node correctly handles Registration APIs whose connections time out

This test checks that a Node can fail over between a set of advertised registries when one fails in an uncontrolled fashion (causing a connection timeout).

Unlike the case of an HTTP 500 error, if a Node uses a system default figure for a connection timeout, it could take up to a minute or more to identify a problem. Nodes are recommended to use a connection timeout figure more in line with their configured heartbeat interval to give them the best chance of failing over to a secondary registry in the event of an error condition.

Note that this test is executed at the same time as test_15 and test_16.

Testing Method

This test uses the same method as test_15, but rather than issuing a 500 error code, one of the registries simulates a connection timeout. When testing this, the Node is permitted an extra HEARTBEAT_INTERVAL before failing over in order to allow it to time out before retrying.

←Advanced Testing · Index↑