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).
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
- 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).
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.