Commit 0a1e0bea authored by Martin Lucina's avatar Martin Lucina

Fixes to PGM wire format description

parent 5fef480a
...@@ -75,48 +75,55 @@ boundaries and a single 0MQ message may span several PGM datagrams. This stream ...@@ -75,48 +75,55 @@ boundaries and a single 0MQ message may span several PGM datagrams. This stream
of data consists of 0MQ messages encapsulated in 'frames' as described in of data consists of 0MQ messages encapsulated in 'frames' as described in
linkzmq:zmq_tcp[7]. linkzmq:zmq_tcp[7].
PGM datagram payload
~~~~~~~~~~~~~~~~~~~~
The following ABNF grammar represents the payload of a single PGM datagram as
used by 0MQ:
....
datagram = (offset data)
offset = 2OCTET
data = *OCTET
....
In order for late joining consumers to be able to identify message boundaries, In order for late joining consumers to be able to identify message boundaries,
each PGM datagram payload starts with a 16-bit unsigned integer in network byte each PGM datagram payload starts with a 16-bit unsigned integer in network byte
order specifying either the offset of the first message 'frame' in the datagram 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 or containing the value 0xFFFF if the datagram contains solely an intermediate
part of a larger message. part of a larger message.
The payload of a single PGM datagram as used by 0MQ can thus be defined by the The following diagram illustrates the layout of a single PGM datagram payload:
following ABNF grammar:
.... ....
datagram = (offset data) +------------------+----------------------+
offset = 2OCTET | offset (16 bits) | data |
data = *OCTET +------------------+----------------------+
.... ....
As already explained above, the data from consecutive datagrams are interpreted The following diagram further illustrates how three example 0MQ frames are laid
as a bytestream that's parsed according to the grammar described in out in consecutive PGM datagram payloads:
linkzmq:zmq_tcp[7].
....
First datagram payload
+--------------+-------------+---------------------+
| Frame offset | Frame 1 | Frame 2, part 1 |
| 0x0000 | (Message 1) | (Message 2, part 1) |
+--------------+-------------+---------------------+
Second datagram payload
+--------------+---------------------+
| Frame offset | Frame 2, part 2 |
| 0xFFFF | (Message 2, part 2) |
+--------------+---------------------+
Third datagram payload
+--------------+----------------------------+-------------+
| Frame offset | Frame 2, final 8 bytes | Frame 3 |
| 0x0008 | (Message 2, final 8 bytes) | (Message 3) |
+--------------+----------------------------+-------------+
....
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 EXAMPLE
------- -------
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment