Imagine you have five OpenLCB CAN segments, connected by small boxes to an Ethernet: You can use an Ethernet-specific protocol (e.g. ala Ethertalk, etc), or you can use IP connections (probably TCP/IP).
The TCP/IP solution seems to require more overhead, but it works about the same on a single Ethernet segment and across multiple segments, wide area links, etc.
The Ethernet-protocol solution seems somewhat simpler (though getting a protocol certified is a lot of work), but can't get traffic off the local Ethernet segment. It spans hubs, but not switches, and would require OpenLCB-specific devices to connect to the larger Internet. So although an Ethernet-specific protocol seems simpler to create, in practice you'd still need to create Ethernet to Internet routers, resulting in an overall increase in engineering effort.
Where Ethernet-specific protocol might be useful is in reducing the configuration load for single-segment implementations. It would be nice if people could plug e.g. five OpenLCB CAN-Ethernet adapters into a single Ethernet and have them find and configure themselves to interconnect. This doesn't require new OpenLCB-specific protocols; it's much more likely that a robust solution could be created using e.g. Bonjour (a form of ZeroConf) and similar standard protocols. Some recommendations here would improve interoperability of implementing devices.
The rest of this note is where we develop that.
Only use well-known, publicly available, commonly implemented protocols
Simple self-configuration is required
Must interoperate with all common PC-like computer types: Windows, Mac, Linux
UDP/IP is not a sufficiently reliable protocol for use with PCs.
Must be straightforward to implement in low cost, low capability devices
Conformance must be testable with reasonable infrastructure.
Use Bonjour/Zeroconf to provide DNS and IP address assignment in the absence of any other network infrastructure, e.g. when creating an ad-hoc network.
Use Bonjour/Zeroconf to advertise and access services.
Use TCP/IP instead of UDP/IP.
In the following, “node” means an OpenLCB node with a native Ethernet connection. This node might be e.g. a gateway to an entire CAN segment, but that doesn't matter to this discussion.
Two types of connections are provided: “point-to-point” and “hub-and-spoke”.
In “point-to-point”, two nodes are connected by a direct TCP/IP connection. This works fine for e.g. two nodes, but using only point-to-point connections doesn't scale well. If there are 10 nodes present, each has to maintain 9 TCP/IP sessions, which is rapidly becoming impractical. On the other hand, it's the simplest possible TCP/IP code.
In the “hub-and-spoke” connection, one node acts as a “hub” and all others connect to it as “spokes”. Each spoke node sends traffic to the hub, and the hub then forwards it to the N-2 other nodes.
When a node comes up, it enquires for a “_openlcb-hub._tcp.local.” service. If found, connect to it.
If not found, and if the node can be a hub (it's not required that all nodes be able to do that), it configures itself to act as a hub and advertises the “_openlcb-hub._tcp.local.” service. Since all that takes time, it then checks again for another node advertising to be a hub. If found, it drops back to connecting to that and removes its service if the connection succeeds.
If all that fails, start advertising as “_openlcb-node._tcp.local.”. Then, check for any other node(s) advertising as “_openlcb-node._tcp.local.” and connect to as many as possible of the ones that are found.
We have also used a protocol where GridConnect-format CAN frames are directly sent back and forth to an Arduino node, which places them on the CAN bus. This is essentially an Ethernet-CAN replacement for the popular USB-CAN adapters. These advertise themselves as “_openlcb-can._tcp.” protocol, by convention on port 12021.
Site hosted by
This is SVN $Revision: 2767 $