mirror of
https://github.com/valitydev/salt.git
synced 2024-11-08 17:33:54 +00:00
8309b69740
As I was working on another project, I ran into some other project doing exactly this. Our current wire protocol is effectively "len-of-thing thing", but msgpack already includes headers in the serialization--making it an iterably consumable format. This means we don't need to use/waste bytes on the wire for the len of the string (esp. since its currently a string serialization of how many bytes). This change simplifies the wire protocol, but still maintains flexibility for changes later-- since we are effectively just msgpacking dicts across the wire. Note: this is a backwards incompatible wire protocol change. This is only being done as TCP is considered "experimental". This will be the last and only change to the wire protocol in a backwards incompatible fashion-- as we are working towards first-class support for the next release.
48 lines
1.5 KiB
ReStructuredText
48 lines
1.5 KiB
ReStructuredText
=============
|
|
TCP Transport
|
|
=============
|
|
|
|
The "tcp" transport is an implementation of Salt's channels using raw tcp sockets.
|
|
Since this isn't using a pre-defined messaging library we will describe the wire
|
|
protocol, message semantics, etc. in this document.
|
|
|
|
|
|
Wire Protocol
|
|
=============
|
|
This implementation over TCP focuses on flexibility over absolute efficiency.
|
|
This means we are okay to spend a couple of bytes of wire space for flexibility
|
|
in the future. That being said, the wire framing is quite efficient and looks
|
|
like:
|
|
|
|
.. code-block:: text
|
|
|
|
msgpack({'head': SOMEHEADER, 'body': SOMEBODY})
|
|
|
|
Since msgpack is an iterably parsed serialization, we can simply write the serialized
|
|
payload to the wire. Within that payload we have two items "head" and "body".
|
|
Head contains header information (such as "message id"). The Body contains the
|
|
actual message that we are sending. With this flexible wire protocol we can
|
|
implement any message semantics that we'd like-- including multiplexed message
|
|
passing on a single socket.
|
|
|
|
|
|
Crypto
|
|
======
|
|
The current implementation uses the same crypto as the ``zeromq`` transport.
|
|
|
|
|
|
Pub Channel
|
|
===========
|
|
For the pub channel we send messages without "message ids" which the remote end
|
|
interprets as a one-way send.
|
|
|
|
.. note::
|
|
|
|
As of today we send all publishes to all minions and rely on minion-side filtering.
|
|
|
|
|
|
Req Channel
|
|
===========
|
|
For the req channel we send messages with a "message id". This "message id" allows
|
|
us to multiplex messages across the socket.
|