|
| 1 | +SECoP UDP discovery protocol |
| 2 | +============================ |
| 3 | + |
| 4 | +Due to the flexibility of the SECoP node system, it is quite likely for multiple |
| 5 | +SEC nodes to be running on a single host. Therefore, it is not sufficient to |
| 6 | +connect to just a single "commonly known" port to discover all available SECoP |
| 7 | +device on that host. |
| 8 | + |
| 9 | +All SEC nodes that wish to support autodiscovery open a UDP socket listening on |
| 10 | +port 10767. Upon receiving a packet on this port, they reply with a packet |
| 11 | +containing the required information to connect to this node. |
| 12 | + |
| 13 | +Format of the packets |
| 14 | +--------------------- |
| 15 | + |
| 16 | +From client to nodes |
| 17 | + The contents of the broadcast packet sent from the client should be a JSON |
| 18 | + object containing the following keys: |
| 19 | + |
| 20 | + - ``SECoP`` set to ``discover``. |
| 21 | + |
| 22 | + Further keys in the object can be specified later. |
| 23 | + |
| 24 | +From node to client |
| 25 | + Receiving a correctly formatted discovery packet, the node should reply to |
| 26 | + the sender address with a JSON object containing the following keys: |
| 27 | + |
| 28 | + - ``SECoP`` set to ``node``. |
| 29 | + - ``port`` set to the TCP port under which the node is reachable. |
| 30 | + - ``equipment_id`` set to the ``equipment_id`` property of the SEC node. |
| 31 | + - ``firmware`` set to the ``firmware`` property of the SEC node. |
| 32 | + - ``description`` set to the ``description`` property of the SEC node, |
| 33 | + shortened if necessary to keep to safe UDP packet size. |
| 34 | + |
| 35 | + If the node is reachable on several ports, it can send the packet once per |
| 36 | + port. |
| 37 | + |
| 38 | + Further keys in the object can be specified later. |
| 39 | + |
| 40 | +Node self-announcement |
| 41 | +---------------------- |
| 42 | + |
| 43 | +Furthermore, a SEC node can self-announce by broadcasting UDP packets to port |
| 44 | +10767 on its own, preferable once at startup or in large intervals. The content |
| 45 | +is exactly the same as in the "node-to-clients" reply packet. |
| 46 | + |
| 47 | +Example |
| 48 | +------- |
| 49 | + |
| 50 | +Here, whitespace is added for readability. In practice, the JSON encoder should |
| 51 | +be configured to omit them to leave maximum space for the content. |
| 52 | + |
| 53 | +From client to nodes:: |
| 54 | + |
| 55 | + {"SECoP": "discover"} |
| 56 | + |
| 57 | +From node to client, or for self-announcement:: |
| 58 | + |
| 59 | + {"SECoP": "node", |
| 60 | + "port": 14932, |
| 61 | + "equipment_id": "mlz_ccr12", |
| 62 | + "firmware": "frappy", |
| 63 | + "description": "A cryostat with pulse tube cooler"} |
| 64 | + |
| 65 | + |
| 66 | +Implementation hints |
| 67 | +-------------------- |
| 68 | + |
| 69 | +- On Linux, the ``SO_REUSEPORT`` socket option needs to be set to 1 to enable |
| 70 | + multiple sockets binding the same port on one host. Received broadcast |
| 71 | + packets will be delivered to all of them simultaneously. |
| 72 | + |
| 73 | +- The maximum safe UDP packet size is 508 bytes. Therefore, the combined length |
| 74 | + of the strings equipment_id, firmware and description can be 430 bytes. The |
| 75 | + first two should be transported entirely, and the description shortened as |
| 76 | + necessary. |
| 77 | + |
| 78 | + |
| 79 | +See also `SECoP RFC 5`_. |
| 80 | + |
| 81 | + |
| 82 | +.. _SECoP RFC 6: https://github.com/SampleEnvironment/SECoP/blob/master/rfcs/RFC-005-udp-discovery.rst |
0 commit comments