IS-04 Node API
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
- A mock IS-04 registry is advertised onto the network via DNS-SD (either multicast or unicast as configured).
- The testing tool waits for the
DNS_SD_BROWSE_TIMEOUTto pass, or for the registry to receive a registration (whichever comes first).
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).
Note that this test is executed at the same time as test_16 and test_16_01.
Testing Method
- Multiple registries are advertised via DNS-SD (either multicast or unicast as configured), each using a different priority (TXT
pri). - The testing tool waits for the
DNS_SD_BROWSE_TIMEOUTto pass, or for the registry with the best priority to receive a registration (whichever comes first). - The testing tool waits for one
HEARTBEAT_INTERVALto pass after all of the Node’s resources have been registered with the registry. - The testing tool disables the first registry, causing it to issue 500 HTTP codes for all subsequent requests.
- The testing tool waits for just over one
HEARTBEAT_INTERVALafter the last heartbeat was received, during which time the Node is expected to attempt to heartbeat with the next best advertised registry. - This process is repeated until all of the test registries have been interacted with, or the first failure is encountered.
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).
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.