Skip to content
Projects
Groups
Snippets
Help
Loading...
Sign in / Register
Toggle navigation
L
libzmq
Project
Project
Details
Activity
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Charts
Packages
Packages
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
submodule
libzmq
Commits
8f90ae8d
Commit
8f90ae8d
authored
Mar 10, 2010
by
Martin Sustrik
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
wire formats in docs clarified
parent
98801ebc
Hide whitespace changes
Inline
Side-by-side
Showing
2 changed files
with
44 additions
and
18 deletions
+44
-18
zmq_pgm.txt
doc/zmq_pgm.txt
+31
-9
zmq_tcp.txt
doc/zmq_tcp.txt
+13
-9
No files found.
doc/zmq_pgm.txt
View file @
8f90ae8d
...
...
@@ -81,20 +81,42 @@ order specifying either the offset of the first message 'frame' in the datagram
or containing the value 0xFFFF if the datagram contains solely an intermediate
part of a larger message.
A single PGM datagram as used by 0MQ can thus be defined by the following ABNF
grammar:
The payload of a single PGM datagram as used by 0MQ can thus be defined by the
following ABNF
grammar:
....
datagram = message / intermediate
message = (frame-offset *data 1*frame) <1>
intermediate = (escape 1*data)
frame-offset = 2OCTET
escape = %xFF %xFF
data = 1*OCTET
datagram = (offset data)
offset = 2OCTET
data = *OCTET
....
<1> 'frame' as defined in linkzmq:zmq_tcp[7].
As already explained above, the data from consecutive datagrams are interpreted
as a bytestream that's parsed according to the grammar described in
linkzmq:zmq_tcp[7].
Each packet thus looks like this:
----
+-----------+------------+------------------+----------------------+
| IP header | PGM header | offset (16 bits) | data |
+-----------+------------+------------------+----------------------+
----
Following example shows how messages are arranged in subsequent packets:
----
+---------------+--------+-----------+-----------------------------+
| PGM/IPheaders | 0x0000 | message 1 | message 2 (part 1) |
+---------------+--------+-----------+-----------------------------+
+---------------+--------+-----------------------------------------+
| PGM/IPheaders | 0xFFFF | message 2 (part 2) |
+---------------+--------+-----------------------------------------+
+---------------+--------+--------------------------+-----------+
| PGM/IPheaders | 0x0008 | message 2 (last 8 bytes) | message 3 |
+---------------+--------+--------------------------+-----------+
----
EXAMPLE
-------
...
...
doc/zmq_tcp.txt
View file @
8f90ae8d
...
...
@@ -54,32 +54,35 @@ A 'peer address' may be specified by either of the following:
WIRE FORMAT
-----------
0MQ messages are transmitted over TCP in frames consisting of the message
length followed by the message data. The size of the message data MUST
correspond to the message length. A single 'frame' can be defined by the
length followed by flags byte and the message data. The length MUST correspond
to the length of the remaining part of the frame.
. A single 'frame' can be defined by the
following ABNF grammar:
....
frame = (message-length message-data)
message-length = OCTET / (escape 8OCTET)
frame = (length flags data)
length = OCTET / (escape 8OCTET)
flags = OCTET
escape = %xFF
message-data
= *OCTET
data
= *OCTET
....
For messages of 0 to 25
4
octets in length, the message length is represented by
For messages of 0 to 25
3
octets in length, the message length is represented by
a single octet:
....
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message size |
Message body
... |
| Message size |
Flags | Message body
... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message body ...
+-+-+-+-+-+-+- ...
....
For messages of 25
5
or more octets in length, the message length is represented
For messages of 25
4
or more octets in length, the message length is represented
by a single octet with the value `255` followed by the message length
represented as a 64-bit unsigned integer in network byte order:
...
...
@@ -91,12 +94,13 @@ represented as a 64-bit unsigned integer in network byte order:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message size ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message size |
Message body
... |
| Message size |
Flags | Message body
... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message body ...
+-+-+-+-+-+-+-+ ...
....
The flags field is reserved and MUST be set to 0.
EXAMPLES
--------
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment