mirror of
https://github.com/valitydev/salt.git
synced 2024-11-09 01:36:48 +00:00
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
|
|
|
|
len(payload) msgpack({'head': SOMEHEADER, 'body': SOMEBODY})
|
|
|
|
The wire protocol is basically two parts, the length of the payload and a payload
|
|
(which is a msgpack'd dict). 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.
|