~Historical: Example: n2k gateway
This is earlier material and largely superceded by the specification
All signal k devices are peer-to peer, but not all devices have the same capabilities. Here we show an N2K gateway starting and in operation.
It has reasonable capabilities, like an ethernet port, IP, mDNS discovery etc, but it does not provide capabilities to aggregate and distribute messages to multiple clients for which it depends on a more capable server. So the boot sequence is as follows:
The first startup sequence collects config and misc data. The keys are just made up for the example, but you can see how the GET messages allow the gateway to any collect required information from the server on a once only basis. The _config branch is a private branch (it starts with a _) and is used in this example for storing vessel specific config data. This provides a central place for the gateway to store arbitrary data, like a list of n2k sentences it should translate, or some misc translation parameters. Data can be saved here using the PUT message.
The two lower boxes represent two completely separate processes.
One receives signalk messages and creates n2k messages. If other pgns are required to be transmitted onto the n2k network, then the gateway should subscribe for the signak data it needs to be able to create the required pgns. A normal subscription will cause the signalk server to send changes immediately, but send data once per second anyway, changed or not. A similar scheme could be used to send the equivalent n2k messages onto the n2k network.
The second process receives n2k pgns, and transmits signalk messages to the server. This process may be simpler, in that it just maps and sends whatever it receives, but it could also provide filtering and other facilities.