Austin Schuh | e84c3ed | 2019-12-14 15:29:48 -0800 | [diff] [blame^] | 1 | #ifndef AOS_NETWORK_MESSAGE_BRIDGE_PROTOCOL_H_ |
| 2 | #define AOS_NETWORK_MESSAGE_BRIDGE_PROTOCOL_H_ |
| 3 | |
| 4 | namespace aos { |
| 5 | namespace message_bridge { |
| 6 | |
| 7 | // The protocol between the message_bridge_client and server is pretty simple. |
| 8 | // The overarching design philosophy is that the server sends data to the |
| 9 | // client, and the client (optionally) sends timestamps back. |
| 10 | // |
| 11 | // 1) A connection is established by the client sending the server a Connect |
| 12 | // flatbuffer on stream 0. |
| 13 | // 2) The server then replies with the data, as it is available, on streams 2 + |
| 14 | // channel_id in the Connect message. |
| 15 | // 3) The client (optionally) replies on stream 1 with MessageHeader flatbuffers |
| 16 | // with the timestamps that the messages were received. |
| 17 | // |
| 18 | // Most of the complexity from there is handling multiple clients and servers |
| 19 | // and persuading SCTP to do what we want. |
| 20 | |
| 21 | // Number of streams reserved for control messages. |
| 22 | constexpr size_t kControlStreams() { return 2; } |
| 23 | // The stream on which Connect messages are sent. |
| 24 | constexpr size_t kConnectStream() { return 0; } |
| 25 | // The stream on which timestamp replies are sent. |
| 26 | constexpr size_t kTimestampStream() { return 1; } |
| 27 | |
| 28 | } // namespace message_bridge |
| 29 | } // namespace aos |
| 30 | |
| 31 | #endif // AOS_NETWORK_MESSAGE_BRIDGE_PROTOCOL_H_ |