Commits

Jens Reimann committed d64044b

add documentation for message channel and OSBP

Comments (0)

Files changed (10)

org.openscada.documentation/protocol/book/index.html

 <!DOCTYPE html>
 <html>
 <head>
-<meta name="generator" content="openSCADA DocDocDoc HTML Book Renderer v0.2.0.201306051907" />
+<meta name="generator" content="openSCADA DocDocDoc HTML Book Renderer v0.3.0.qualifier" />
 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
 <title>openSCADA Protocol Description</title>
 <link href="styles/defaults.css" rel="stylesheet">
 <body>
 <div class="tocbox">
 <div class="heading toc">Table of contents</div>
-<div class="tocentry level_1"><a href="#section_1"><span class="number">1</span><span class="title">Introduction</span></a></div>
-<div class="tocentry level_1"><a href="#section_2"><span class="number">2</span><span class="title">NGP – NextGenerationProtocol</span></a></div>
-<div class="tocentry level_2"><a href="#section_2.1"><span class="number">2.1</span><span class="title">Overview</span></a></div>
-<div class="tocentry level_2"><a href="#section_2.2"><span class="number">2.2</span><span class="title">Message channel</span></a></div>
-<div class="tocentry level_3"><a href="#section_2.2.1"><span class="number">2.2.1</span><span class="title">Message types</span></a></div>
-<div class="tocentry level_3"><a href="#section_2.2.2"><span class="number">2.2.2</span><span class="title">Message sequence</span></a></div>
-<div class="tocentry level_3"><a href="#section_2.2.3"><span class="number">2.2.3</span><span class="title">Exception Handling</span></a></div>
-<div class="tocentry level_3"><a href="#section_2.2.4"><span class="number">2.2.4</span><span class="title">Message Codec</span></a></div>
-<div class="tocentry level_1"><a href="#section_3"><span class="number">3</span><span class="title">Appendices</span></a></div>
-<div class="tocentry level_2"><a href="#section_license"><span class="number">3.I</span><span class="title">GNU Free Documentation License</span></a></div>
+<div class="tocentry level_1"><a href="#section_1"><span class="number">1</span><span class="title">About this document</span></a></div>
+<div class="tocentry level_1"><a href="#section_2"><span class="number">2</span><span class="title">Introduction</span></a></div>
+<div class="tocentry level_1"><a href="#section_3"><span class="number">3</span><span class="title">Message channel</span></a></div>
+<div class="tocentry level_2"><a href="#section_3.1"><span class="number">3.1</span><span class="title">Message types</span></a></div>
+<div class="tocentry level_2"><a href="#section_3.2"><span class="number">3.2</span><span class="title">Message sequence</span></a></div>
+<div class="tocentry level_2"><a href="#section_3.3"><span class="number">3.3</span><span class="title">Exception Handling</span></a></div>
+<div class="tocentry level_2"><a href="#section_3.4"><span class="number">3.4</span><span class="title">Message Codec</span></a></div>
+<div class="tocentry level_2"><a href="#section_3.5"><span class="number">3.5</span><span class="title">Message Payload</span></a></div>
+<div class="tocentry level_2"><a href="#section_3.6"><span class="number">3.6</span><span class="title">Message – HELLO</span></a></div>
+<div class="tocentry level_2"><a href="#section_3.7"><span class="number">3.7</span><span class="title">Message – ACCEPT</span></a></div>
+<div class="tocentry level_2"><a href="#section_3.8"><span class="number">3.8</span><span class="title">Message – START</span></a></div>
+<div class="tocentry level_2"><a href="#section_3.9"><span class="number">3.9</span><span class="title">Message – CLOSE</span></a></div>
+<div class="tocentry level_2"><a href="#section_3.10"><span class="number">3.10</span><span class="title">Message – PING</span></a></div>
+<div class="tocentry level_2"><a href="#section_3.11"><span class="number">3.11</span><span class="title">Message – PONG</span></a></div>
+<div class="tocentry level_1"><a href="#section_4"><span class="number">4</span><span class="title">Handshake phases</span></a></div>
+<div class="tocentry level_2"><a href="#section_4.1"><span class="number">4.1</span><span class="title">Handshake properties</span></a></div>
+<div class="tocentry level_1"><a href="#section_5"><span class="number">5</span><span class="title">Serialization with OSBP</span></a></div>
+<div class="tocentry level_2"><a href="#section_5.1"><span class="number">5.1</span><span class="title">Value types</span></a></div>
+<div class="tocentry level_3"><a href="#section_5.1.1"><span class="number">5.1.1</span><span class="title">String</span></a></div>
+<div class="tocentry level_3"><a href="#section_5.1.2"><span class="number">5.1.2</span><span class="title">Boolean</span></a></div>
+<div class="tocentry level_3"><a href="#section_5.1.3"><span class="number">5.1.3</span><span class="title">Variant</span></a></div>
+<div class="tocentry level_2"><a href="#section_5.2"><span class="number">5.2</span><span class="title">Message structure</span></a></div>
+<div class="tocentry level_2"><a href="#section_5.3"><span class="number">5.3</span><span class="title">Encoding of fields</span></a></div>
+<div class="tocentry level_3"><a href="#section_5.3.1"><span class="number">5.3.1</span><span class="title">Null Values</span></a></div>
+<div class="tocentry level_3"><a href="#section_5.3.2"><span class="number">5.3.2</span><span class="title">Integer</span></a></div>
+<div class="tocentry level_3"><a href="#section_5.3.3"><span class="number">5.3.3</span><span class="title">Long</span></a></div>
+<div class="tocentry level_3"><a href="#section_5.3.4"><span class="number">5.3.4</span><span class="title">Double</span></a></div>
+<div class="tocentry level_3"><a href="#section_5.3.5"><span class="number">5.3.5</span><span class="title">Boolean</span></a></div>
+<div class="tocentry level_3"><a href="#section_5.3.6"><span class="number">5.3.6</span><span class="title">String</span></a></div>
+<div class="tocentry level_3"><a href="#section_5.3.7"><span class="number">5.3.7</span><span class="title">Enum</span></a></div>
+<div class="tocentry level_3"><a href="#section_5.3.8"><span class="number">5.3.8</span><span class="title">Properties map</span></a></div>
+<div class="tocentry level_3"><a href="#section_5.3.9"><span class="number">5.3.9</span><span class="title">Variant</span></a></div>
+<div class="tocentry level_3"><a href="#section_5.3.10"><span class="number">5.3.10</span><span class="title">Variant Map</span></a></div>
+<div class="tocentry level_2"><a href="#section_5.4"><span class="number">5.4</span><span class="title">Values</span></a></div>
+<div class="tocentry level_1"><a href="#section_6"><span class="number">6</span><span class="title">Appendices</span></a></div>
+<div class="tocentry level_2"><a href="#section_license"><span class="number">6.I</span><span class="title">GNU Free Documentation License</span></a></div>
 </div>
 <div class="bodybox">
-<div class="book_title">openSCADA Protocol Description</div><div class="book_authors">Authors</div><ul class="book_author_list"><li>Jens Reimann (ctron@dentrassi.de)</li></ul><div class="book_copyright">Copyright &copy; 2013</div><p class="book_copyrightText">Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled &quot;GNU Free Documentation License&quot;.</p><div id="section_1" class="heading level_1"><span class="number">1</span><span class="title">Introduction</span></div>
+<div class="book_title">openSCADA Protocol Description</div><div class="book_authors">Authors</div><ul class="book_author_list"><li>Jens Reimann (ctron@dentrassi.de)</li></ul><div class="book_copyright">Copyright &copy; 2013</div><p class="book_copyrightText">Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled &quot;GNU Free Documentation License&quot;.</p><div id="section_1" class="heading level_1"><span class="number">1</span><span class="title">About this document</span></div>
 <p>
 This document describes the internal openSCADA protocols.
 </p>
 The reader of this document should be familiar with TCP/IP based network 
 communication.
 </p>
-<div id="section_2" class="heading level_1"><span class="number">2</span><span class="title">NGP – NextGenerationProtocol</span></div>
+<div id="section_2" class="heading level_1"><span class="number">2</span><span class="title">Introduction</span></div>
 <p>
 The <q>NPG</q> protocol (<q>next generation protocol</q>) is the
 successor of the <q>GMPP/NET</q> protocol of openSCADA. it was created in order
 to fix some performance issues and make it easier to extend the protocol. 
 </p>
-<div id="section_2.1" class="heading level_2"><span class="number">2.1</span><span class="title">Overview</span></div>
 <p>
 NGP is a plain Client/Server TCP/IP protocol. The server side is also the TCP server. So an
 DA server (aka <q>Hive</q>, <q>Driver Module</q>) is the
 The result of the second layer is a <q>stream</q> of interpreted
 messages which make up the real data of the openSCADA protocol that is transmitted.
 </p>
-<div id="section_2.2" class="heading level_2"><span class="number">2.2</span><span class="title">Message channel</span></div>
-<div id="section_2.2.1" class="heading level_3"><span class="number">2.2.1</span><span class="title">Message types</span></div>
+<div id="section_3" class="heading level_1"><span class="number">3</span><span class="title">Message channel</span></div>
+<p>
+The message channel is the first layer over the TCP protocol. It provides a handshake
+mechanism and a way to send <q>data messages</q> over the TCP, stream based, link.
+It allows to add features like encryption and compression and defines communication parameters
+for the data inside the messages. It does not decode the data messages itself.
+</p>
+<div id="section_3.1" class="heading level_2"><span class="number">3.1</span><span class="title">Message types</span></div>
 <p>
 The message channel sends frames. Frames have a distinct type and encoding. The following frame
 types are defined:
 </tr>
 </tbody>
 </table>
-<div id="section_2.2.2" class="heading level_3"><span class="number">2.2.2</span><span class="title">Message sequence</span></div>
+<div id="section_3.2" class="heading level_2"><span class="number">3.2</span><span class="title">Message sequence</span></div>
 <p>
-The connection is initiated by the client. The client openes the TCP connection and once this
+The connection is initiated by the client. The client opens the TCP connection and once this
 connection is established a HELLO message is sent. The server will then process the message
 and reply with an ACCEPT message if the connection can be opened. Otherwise a CLOSE message should
 be sent and the connection will be terminated by the server.  
 data communication. Both sides may not sent PING/PONG messages. And most of all
 messages of the type MESSAGE for transmitting data.
 </p>
-<div id="section_2.2.3" class="heading level_3"><span class="number">2.2.3</span><span class="title">Exception Handling</span></div>
+<div id="section_3.3" class="heading level_2"><span class="number">3.3</span><span class="title">Exception Handling</span></div>
 <p>
 In case anything goes wrong each side may close the TCP connection at any time.
 </p>
-<div id="section_2.2.4" class="heading level_3"><span class="number">2.2.4</span><span class="title">Message Codec</span></div>
+<div id="section_3.4" class="heading level_2"><span class="number">3.4</span><span class="title">Message Codec</span></div>
+<p>
+Each message consists of a common header and a payload section. The following table shows
+the structure of the common header.
+</p>
+<table class="dcm_simple dcm_structure"><colgroup>
+<col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Index</th>
+<th>Length</th>
+<th>Name</th>
+<th>Type</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td>0</td>
+<td>1</td>
+<td>version</td>
+<td>byte</td>
+<td>
+Version identifier, contains 0x01 at the moment.</td>
+</tr>
+<tr>
+<td>1</td>
+<td>1</td>
+<td>messageType</td>
+<td>byte</td>
+<td>
+The numeric value of the message type (HELLO, ACCEPT, &hellip;).</td>
+</tr>
+<tr>
+<td>2</td>
+<td>4</td>
+<td>payloadSize</td>
+<td>int32</td>
+<td>
+The number of bytes following. Although this is a signed integer, it must never be negative.</td>
+</tr>
+<tr>
+<td>6</td>
+<td>payloadSize</td>
+<td>payloadData</td>
+<td>byte[]</td>
+<td>
+Message payload, must be encoded/decoded depending on the mesage type.</td>
+</tr>
+</tbody>
+</table>
+<div id="section_3.5" class="heading level_2"><span class="number">3.5</span><span class="title">Message Payload</span></div>
+<p>All messages except the MESSAGE message are handled by the message channel itself. Therefore the encoding of these
+messages are part of the message channel. The MESSAGE message contains only payload data which is handeled by the second layer and
+not the message channel itself. Therefore the handshake phase must come up witch a serialzation method that describes
+what is inside the MESSAGE messages. And this requires the handshake to complete before any MESSAGE messages can be sent. </p>
+<div id="section_3.6" class="heading level_2"><span class="number">3.6</span><span class="title">Message – HELLO</span></div>
+<p>The payload data is a property (string to string) map. The number of entries, as 32 bit signed integer. Repeating for each entry:</p>
+<ul>
+<li>A null byte terminated string without length prefix as <q>key</q> string</li>
+<li>A null byte terminated string without length prefix as <q>value</q> string</li>
+</ul>
+<div id="section_3.7" class="heading level_2"><span class="number">3.7</span><span class="title">Message – ACCEPT</span></div>
+<p>The payload data is a property (string to string) map. The number of entries, as 32 bit signed integer. Repeating for each entry:</p>
+<ul>
+<li>A null byte terminated string without length prefix as <q>key</q> string</li>
+<li>A null byte terminated string without length prefix as <q>value</q> string</li>
+</ul>
+<div id="section_3.8" class="heading level_2"><span class="number">3.8</span><span class="title">Message – START</span></div>
+<p>This message has no message payload.</p>
+<div id="section_3.9" class="heading level_2"><span class="number">3.9</span><span class="title">Message – CLOSE</span></div>
+<table class="dcm_simple dcm_structure"><colgroup>
+<col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Index</th>
+<th>Length</th>
+<th>Name</th>
+<th>Type</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td>0</td>
+<td>…</td>
+<td>reason</td>
+<td>string</td>
+<td>
+A null byte terminated string without lenght prefix.</td>
+</tr>
+<tr>
+<td>0 + reason</td>
+<td>…</td>
+<td>reasonCode</td>
+<td>int32</td>
+<td>
+A reason code.</td>
+</tr>
+</tbody>
+</table>
+<div id="section_3.10" class="heading level_2"><span class="number">3.10</span><span class="title">Message – PING</span></div>
+<p>This message has no message payload.</p>
+<div id="section_3.11" class="heading level_2"><span class="number">3.11</span><span class="title">Message – PONG</span></div>
+<p>This message has no message payload.</p>
+<div id="section_4" class="heading level_1"><span class="number">4</span><span class="title">Handshake phases</span></div>
+<p>
+There are four phases in the handshake.
+</p>
+<p>Phase 1: Initially the client starts the communication by opening with a HELLO message. The message may contain a set of
+properties of capabilities and strictions of the client.</p>
+<p>Phase 2: Next the server will validate these properties and evaluate the resulting properties which are the result of the handshake. A common ground
+for further communication.</p>
+<p>Phase 3: This result will be sent to the client in an ACCEPT message and after that applied to its own communication channel. It is not possible
+to already send the first message with the new communication parameters since the client still does not know them.</p>
+<p>Phase 4: The client receives the communication parameters in the ACCEPT message and applies the communication parameters as well. It sends
+out a START message, with the new communication parameters, and both sides are ready for data transmission.</p>
+<p>If the server cannot accept the connections, maybe due to the fact that the handshake did not work out, it can close the connection by
+optionally sending a CLOSE message first and then closing the TCP connection. Also can the client close the TCP connection after receiving the ACCEPT
+message it the communication parameters are not as excepted.</p>
+<div id="section_4.1" class="heading level_2"><span class="number">4.1</span><span class="title">Handshake properties</span></div>
+<p>In general any handshake parameters can be sent in the HELLO and ACCEPT messages. Each side must handle unkown properties by simply ignoring them.
+Each side has to evaluate if the other side is <q>good enough</q> for communication. So for example if the client requests SSL encryption but
+the server does not not about SSL, it would simply ignore the clients request and not report anything about SSL back. Now the client can decide if it wants
+to further communicate with this server or close the connection instead. Since no user information has been transmitted up to now this is ok.</p>
+<p>The following list therefore only documents the handshake properties which are defined up to now and are in use. The recommendation 
+column specifies if support of this property is highly recommended or an optional feature.</p>
+<table class="dcm_simple"><caption>
+A list of handshake properties
+</caption>
+<colgroup>
+<col class="dcm_left" />
+<col class="dcm_left" />
+<col class="dcm_left" />
+<col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Name</th>
+<th>Recommendation</th>
+<th>Sent by</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td class="dcm_left">timeout</td>
+<td class="dcm_left">Recommended</td>
+<td class="dcm_left">Client, Server</td>
+<td class="dcm_left">The communication timeout in milliseconds. The client can request a value and
+the server may correct that value. The result is sent back to the client.</td>
+</tr>
+<tr>
+<td class="dcm_left">startSession.enable</td>
+<td class="dcm_left">Required</td>
+<td class="dcm_left">Client, Server</td>
+<td class="dcm_left">This is a feature flag, indicating that the START message is used.
+In older versions this START message was unknown and communication could start directly
+after sending the ACCEPT message. This behaviour is still available when <em>not</em>
+sending the <span class="objectName">startSession.enable</span> property. But this
+behaviour is deprecated and should <em>not</em> be used anymore.</td>
+</tr>
+<tr>
+<td class="dcm_left">protocol.*</td>
+<td class="dcm_left">Required</td>
+<td class="dcm_left">Client</td>
+<td class="dcm_left">All properties starting with <span class="objectName">protocol.</span> will
+be considered candiates for the protocol selection that is used for encoding the MESSAGE messages.
+So if the protocol <span class="objectName">osbp.v1</span> is available the property
+<span class="objectName">protocol.osbp.v1</span> needs to be set to the value 
+<span class="objectName">true</span>.</td>
+</tr>
+<tr>
+<td class="dcm_left">preferredClientProtocols</td>
+<td class="dcm_left">Recommended</td>
+<td class="dcm_left">Client</td>
+<td class="dcm_left">A request from the client to use a specific protocol if multiple are possible.
+The server can override or ignore this setting. It is a list of protocols delimited by comma.</td>
+</tr>
+<tr>
+<td class="dcm_left">protocol</td>
+<td class="dcm_left">Required</td>
+<td class="dcm_left">Server</td>
+<td class="dcm_left">The protocol selected by the server for MESSAGE messages.</td>
+</tr>
+<tr>
+<td class="dcm_left">requestSsl</td>
+<td class="dcm_left">Optional</td>
+<td class="dcm_left">Client</td>
+<td class="dcm_left">The client requests SSL encryption.</td>
+</tr>
+<tr>
+<td class="dcm_left">useSsl</td>
+<td class="dcm_left">Optional</td>
+<td class="dcm_left">Server</td>
+<td class="dcm_left">The server uses SSL encryption. This flag should not be set if the client did 
+not request for SSL encryption since the client will most likely not support it then. If
+this is howerever a problem for the server, the server can close the connection instead.</td>
+</tr>
+</tbody>
+</table>
+<div id="section_5" class="heading level_1"><span class="number">5</span><span class="title">Serialization with OSBP</span></div>
+<p>
+The <q>openSCADA Binary Protocol</q> codec is the default codec used
+for the NGP protocol. It describes the format which is used to encode structure into
+a binary form so that these structures can be sent over the message channel.
+</p>
+<p>
+The OSBP knows some primary value types and can construct complex structures based on these.
+While other serialization methods may provide enhanced data structures with different types
+the NGP protocol stack requires the implementor to only send messages which can be
+represented by the OSBP codec. Still other protocol stacks using the message channel
+can use different ways of encoding the payload messages.
+</p>
+<p>
+All values are encoded in network byte order.
+</p>
+<div id="section_5.1" class="heading level_2"><span class="number">5.1</span><span class="title">Value types</span></div>
+<p>The following table shows the primary value types:</p>
+<table class="dcm_simple"><colgroup>
+<col class="dcm_left" />
+<col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Type</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td class="dcm_left">Integer</td>
+<td class="dcm_left">signed 32bit integer</td>
+</tr>
+<tr>
+<td class="dcm_left">Long</td>
+<td class="dcm_left">signed 64bit integer</td>
+</tr>
+<tr>
+<td class="dcm_left">Float</td>
+<td class="dcm_left">64bit floating point according to IEEE 754</td>
+</tr>
+<tr>
+<td class="dcm_left">Boolean</td>
+<td class="dcm_left">boolean value</td>
+</tr>
+<tr>
+<td class="dcm_left">String</td>
+<td class="dcm_left">unicode string</td>
+</tr>
+<tr>
+<td class="dcm_left">Enum</td>
+<td class="dcm_left">An enum, enum values have assigned an ordinal numeric value starting with zero.</td>
+</tr>
+<tr>
+<td class="dcm_left">Variant</td>
+<td class="dcm_left">The openSCADA Variant Type</td>
+</tr>
+<tr>
+<td class="dcm_left">Properties Map</td>
+<td class="dcm_left">A map of String to String properties</td>
+</tr>
+<tr>
+<td class="dcm_left">Variant Map</td>
+<td class="dcm_left">A map of String to Variant</td>
+</tr>
+<tr>
+<td class="dcm_left">Structure</td>
+<td class="dcm_left">A sub structure</td>
+</tr>
+</tbody>
+</table>
+<div id="section_5.1.1" class="heading level_3"><span class="number">5.1.1</span><span class="title">String</span></div>
+<p>
+Strings are encoded as UTF-8 byte arrays with a 4 byte size prefix and <em>no</em> null terminating character.
+</p>
+<div id="section_5.1.2" class="heading level_3"><span class="number">5.1.2</span><span class="title">Boolean</span></div>
+<p>Booleans are encoded as byte. <span class="objectName">true</span> is encoded as <span class="objectName">0xFF</span> and
+<span class="objectName">false</span> as <span class="objectName">0x00</span>. When reading a boolean value everything else then 
+<span class="objectName">0x00</span> is considered as <span class="objectName">true</span>.</p>
+<div id="section_5.1.3" class="heading level_3"><span class="number">5.1.3</span><span class="title">Variant</span></div>
+<p>
+The openSCADA variant type is encoded as follows:
+</p>
+<p>The first byte is the variant type ordinal. Followed by the actual value data.</p>
+<table class="dcm_simple"><colgroup>
+<col class="dcm_left" />
+<col class="dcm_right" />
+<col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Variant Type</th>
+<th>Ordinal</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td class="dcm_left">BOOLEAN</td>
+<td class="dcm_right">0</td>
+<td class="dcm_left">A single boolean value, as byte</td>
+</tr>
+<tr>
+<td class="dcm_left">INT32</td>
+<td class="dcm_right">1</td>
+<td class="dcm_left">An 32bit signed integer</td>
+</tr>
+<tr>
+<td class="dcm_left">INT64</td>
+<td class="dcm_right">2</td>
+<td class="dcm_left">An 64bit signed integer</td>
+</tr>
+<tr>
+<td class="dcm_left">DOUBLE</td>
+<td class="dcm_right">3</td>
+<td class="dcm_left">An 64bit floating point according to IEEE 754</td>
+</tr>
+<tr>
+<td class="dcm_left">STRING</td>
+<td class="dcm_right">4</td>
+<td class="dcm_left">A string, encoded as a length prefixed UTF-8 string</td>
+</tr>
+<tr>
+<td class="dcm_left">NULL</td>
+<td class="dcm_right">5</td>
+<td class="dcm_left">A null value, contains no additional data</td>
+</tr>
+</tbody>
+</table>
+<div id="section_5.2" class="heading level_2"><span class="number">5.2</span><span class="title">Message structure</span></div>
+<p>
+Each message has a common header followed by the message structure. The message structure itself consist of fields. Each fields
+must be of one of the primary data types, but still can also be a structure. A structure is encoded right at the point where
+it is specified.
+</p>
+<table class="dcm_simple dcm_structure"><caption>
+Common message header
+</caption>
+<colgroup>
+<col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Index</th>
+<th>Length</th>
+<th>Name</th>
+<th>Type</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td>0</td>
+<td>4</td>
+<td>messageCode</td>
+<td>int32</td>
+<td>
+Message code as 32bit signed integer</td>
+</tr>
+<tr>
+<td>4</td>
+<td>1</td>
+<td>numberOfFields</td>
+<td>byte</td>
+<td>
+The number of fields following this field</td>
+</tr>
+<tr>
+<td>5</td>
+<td>…</td>
+<td>structure</td>
+<td>Structure</td>
+<td>
+Actual message payload, with a maximum of fields specified in &quot;numberOfFields&quot;.</td>
+</tr>
+</tbody>
+</table>
+<p>
+Each field has a type modifier which can be: 
+</p>
 <table class="dcm_simple"><colgroup>
 <col class="dcm_left" />
 <col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Modifier</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td class="dcm_left">REQUIRED</td>
+<td class="dcm_left">Cardinality of 1</td>
+</tr>
+<tr>
+<td class="dcm_left">OPTIONAL</td>
+<td class="dcm_left">Cardinality of 0&hellip;1</td>
+</tr>
+<tr>
+<td class="dcm_left">ORDERED</td>
+<td class="dcm_left">Cardinality of 0&hellip;*, with a specific order, without uniqueness of items</td>
+</tr>
+<tr>
+<td class="dcm_left">UNIQUE</td>
+<td class="dcm_left">Cardinality of 0&hellip;*, without a specific order, with unique items</td>
+</tr>
+</tbody>
+</table>
+<p>
+In Java REQUIRED fields are non-null and primitive type of possible. OPTIONAL fields will become non-primitve types.
+ORDERED fields become types based on List. And UNIQUE will be created as Set.   
+</p>
+<div id="section_5.3" class="heading level_2"><span class="number">5.3</span><span class="title">Encoding of fields</span></div>
+<p>
+Fields can be encoded in any order as long as the structure grouping is maintained. This is possible due to the numbering of the fields.
+Also fields which are unknown must be ignored by the decoder, a warning may be print out. This is used for future enhancements where fields are
+present but unknown by the receiver. Yet if a field is present but has the wrong type it is considered a protocol error and the connection must be closed. 
+</p>
+<p>
+Each field too has a common header:
+</p>
+<table class="dcm_simple dcm_structure"><caption>
+Common header of fields
+</caption>
+<colgroup>
+<col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Index</th>
+<th>Length</th>
+<th>Name</th>
+<th>Type</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td>0</td>
+<td>1</td>
+<td>fieldNumber</td>
+<td>byte</td>
+<td>
+The field number</td>
+</tr>
+<tr>
+<td>1</td>
+<td>2</td>
+<td>typeId</td>
+<td>byte</td>
+<td>
+The encoded type id of the field</td>
+</tr>
+</tbody>
+</table>
+<div id="section_5.3.1" class="heading level_3"><span class="number">5.3.1</span><span class="title">Null Values</span></div>
+<p>
+If the field is optional and the value is not set the type id is <span class="objectName">TYPE_NULL</span> independent of the type.
+</p>
+<div id="section_5.3.2" class="heading level_3"><span class="number">5.3.2</span><span class="title">Integer</span></div>
+<p>If the field is specified as OPTIONAL or REQUIRED:</p>
+<table class="dcm_simple dcm_structure"><colgroup>
+<col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Index</th>
+<th>Length</th>
+<th>Name</th>
+<th>Type</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td>0</td>
+<td>1</td>
+<td>fieldNumber</td>
+<td>byte</td>
+<td>
+The field number</td>
+</tr>
+<tr>
+<td>1</td>
+<td>1</td>
+<td>typeId</td>
+<td>byte</td>
+<td>
+TYPE_INT</td>
+</tr>
+<tr>
+<td>2</td>
+<td>4</td>
+<td>value</td>
+<td>int32</td>
+<td>
+The value</td>
+</tr>
+</tbody>
+</table>
+<p>If the field is specified as ORDERED or UNIQUE:</p>
+<table class="dcm_simple dcm_structure"><colgroup>
+<col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Index</th>
+<th>Length</th>
+<th>Name</th>
+<th>Type</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td>0</td>
+<td>1</td>
+<td>fieldNumber</td>
+<td>byte</td>
+<td>
+The field number</td>
+</tr>
+<tr>
+<td>1</td>
+<td>1</td>
+<td>typeId</td>
+<td>byte</td>
+<td>
+TYPE_INT_LIST</td>
+</tr>
+<tr>
+<td>2</td>
+<td>4</td>
+<td>numerOfEntries</td>
+<td>int32</td>
+<td>
+The number of values following</td>
+</tr>
+<tr>
+<td>6</td>
+<td>…</td>
+<td>value</td>
+<td>int32[]</td>
+<td>
+The values</td>
+</tr>
+</tbody>
+</table>
+<div id="section_5.3.3" class="heading level_3"><span class="number">5.3.3</span><span class="title">Long</span></div>
+<p>If the field is specified as OPTIONAL or REQUIRED:</p>
+<table class="dcm_simple dcm_structure"><colgroup>
 <col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Index</th>
+<th>Length</th>
+<th>Name</th>
+<th>Type</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td>0</td>
+<td>1</td>
+<td>fieldNumber</td>
+<td>byte</td>
+<td>
+The field number</td>
+</tr>
+<tr>
+<td>1</td>
+<td>1</td>
+<td>typeId</td>
+<td>byte</td>
+<td>
+TYPE_LONG</td>
+</tr>
+<tr>
+<td>2</td>
+<td>8</td>
+<td>value</td>
+<td>int64</td>
+<td>
+The value</td>
+</tr>
+</tbody>
+</table>
+<p>If the field is specified as ORDERED or UNIQUE:</p>
+<table class="dcm_simple dcm_structure"><colgroup>
 <col class="dcm_left" />
 </colgroup>
 <thead><tr>
 <th>Index</th>
-<th>Field</th>
+<th>Length</th>
+<th>Name</th>
 <th>Type</th>
 <th>Description</th>
 </tr></thead>
 <tbody>
 <tr>
-<td class="dcm_left">0</td>
-<td class="dcm_left">Version</td>
-<td class="dcm_left">byte</td>
-<td class="dcm_left">Version identifier, contains 0x01 at the moment.</td>
+<td>0</td>
+<td>1</td>
+<td>fieldNumber</td>
+<td>byte</td>
+<td>
+The field number</td>
 </tr>
 <tr>
-<td class="dcm_left">1</td>
-<td class="dcm_left">Message type/numeric</td>
-<td class="dcm_left">byte</td>
-<td class="dcm_left">The numeric value of the message.</td>
+<td>1</td>
+<td>1</td>
+<td>typeId</td>
+<td>byte</td>
+<td>
+TYPE_LONG_LIST</td>
 </tr>
 <tr>
-<td class="dcm_left">2</td>
-<td class="dcm_left">Data Size</td>
-<td class="dcm_left">32bit signed integer</td>
-<td class="dcm_left">The amout of data following. Although this is a signed integer, it must never be negative.</td>
+<td>2</td>
+<td>4</td>
+<td>numerOfEntries</td>
+<td>int32</td>
+<td>
+The number of values following</td>
+</tr>
+<tr>
+<td>6</td>
+<td>…</td>
+<td>value</td>
+<td>int64[]</td>
+<td>
+The values</td>
+</tr>
+</tbody>
+</table>
+<div id="section_5.3.4" class="heading level_3"><span class="number">5.3.4</span><span class="title">Double</span></div>
+<p>If the field is specified as OPTIONAL or REQUIRED:</p>
+<table class="dcm_simple dcm_structure"><colgroup>
+<col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Index</th>
+<th>Length</th>
+<th>Name</th>
+<th>Type</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td>0</td>
+<td>1</td>
+<td>fieldNumber</td>
+<td>byte</td>
+<td>
+The field number</td>
+</tr>
+<tr>
+<td>1</td>
+<td>1</td>
+<td>typeId</td>
+<td>byte</td>
+<td>
+TYPE_DOUBLE</td>
+</tr>
+<tr>
+<td>2</td>
+<td>8</td>
+<td>value</td>
+<td>double</td>
+<td>
+The value encoded according to IEEE 754</td>
+</tr>
+</tbody>
+</table>
+<p>If the field is specified as ORDERED or UNIQUE:</p>
+<table class="dcm_simple dcm_structure"><colgroup>
+<col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Index</th>
+<th>Length</th>
+<th>Name</th>
+<th>Type</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td>0</td>
+<td>1</td>
+<td>fieldNumber</td>
+<td>byte</td>
+<td>
+The field number</td>
+</tr>
+<tr>
+<td>1</td>
+<td>1</td>
+<td>typeId</td>
+<td>byte</td>
+<td>
+TYPE_DOUBLE_LIST</td>
+</tr>
+<tr>
+<td>2</td>
+<td>4</td>
+<td>numerOfEntries</td>
+<td>int32</td>
+<td>
+The number of values following</td>
+</tr>
+<tr>
+<td>6</td>
+<td>…</td>
+<td>value</td>
+<td>double[]</td>
+<td>
+The values encoded according to IEEE 754</td>
+</tr>
+</tbody>
+</table>
+<div id="section_5.3.5" class="heading level_3"><span class="number">5.3.5</span><span class="title">Boolean</span></div>
+<p>If the field is specified as OPTIONAL or REQUIRED:</p>
+<table class="dcm_simple dcm_structure"><colgroup>
+<col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Index</th>
+<th>Length</th>
+<th>Name</th>
+<th>Type</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td>0</td>
+<td>1</td>
+<td>fieldNumber</td>
+<td>byte</td>
+<td>
+The field number</td>
+</tr>
+<tr>
+<td>1</td>
+<td>1</td>
+<td>typeId</td>
+<td>byte</td>
+<td>
+TYPE_BOOLEAN</td>
+</tr>
+<tr>
+<td>2</td>
+<td>1</td>
+<td>value</td>
+<td>byte</td>
+<td>
+The value, 0x00 = false, 0xFF = true</td>
+</tr>
+</tbody>
+</table>
+<p>If the field is specified as ORDERED or UNIQUE:</p>
+<table class="dcm_simple dcm_structure"><colgroup>
+<col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Index</th>
+<th>Length</th>
+<th>Name</th>
+<th>Type</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td>0</td>
+<td>1</td>
+<td>fieldNumber</td>
+<td>byte</td>
+<td>
+The field number</td>
+</tr>
+<tr>
+<td>1</td>
+<td>1</td>
+<td>typeId</td>
+<td>byte</td>
+<td>
+TYPE_BOOLEAN_LIST</td>
+</tr>
+<tr>
+<td>2</td>
+<td>4</td>
+<td>numerOfEntries</td>
+<td>int32</td>
+<td>
+The number of values following</td>
+</tr>
+<tr>
+<td>6</td>
+<td>…</td>
+<td>value</td>
+<td>byte[]</td>
+<td>
+The values</td>
+</tr>
+</tbody>
+</table>
+<p>
+Although multiple booleans (ORDERED) could be encoded as a bit array, they are in fact not. Each boolean value is encoded in a seperate byte.
+The fact is that there a not <q>lists of booleans</q> defined up to now, a <q>set of boolean</q> would be possible but
+only contain 2 bits maximum. Still it is possible to handle your bits directly as integer or log value instead.
+</p>
+<div id="section_5.3.6" class="heading level_3"><span class="number">5.3.6</span><span class="title">String</span></div>
+<p>If the field is specified as OPTIONAL or REQUIRED:</p>
+<table class="dcm_simple dcm_structure"><colgroup>
+<col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Index</th>
+<th>Length</th>
+<th>Name</th>
+<th>Type</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td>0</td>
+<td>1</td>
+<td>fieldNumber</td>
+<td>byte</td>
+<td>
+The field number</td>
+</tr>
+<tr>
+<td>1</td>
+<td>1</td>
+<td>typeId</td>
+<td>byte</td>
+<td>
+TYPE_STRING</td>
+</tr>
+<tr>
+<td>2</td>
+<td>4</td>
+<td>stringDataSize</td>
+<td>int32</td>
+<td>
+The number of string bytes following</td>
+</tr>
+<tr>
+<td>6</td>
+<td>stringDataSize</td>
+<td>value</td>
+<td>byte</td>
+<td>
+The string encoded as a UTF-8 string without null byte terminate</td>
+</tr>
+</tbody>
+</table>
+<p>If the field is specified as ORDERED or UNIQUE:</p>
+<table class="dcm_simple dcm_structure"><colgroup>
+<col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Index</th>
+<th>Length</th>
+<th>Name</th>
+<th>Type</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td>0</td>
+<td>1</td>
+<td>fieldNumber</td>
+<td>byte</td>
+<td>
+The field number</td>
+</tr>
+<tr>
+<td>1</td>
+<td>1</td>
+<td>typeId</td>
+<td>byte</td>
+<td>
+TYPE_STRING_LIST</td>
+</tr>
+<tr>
+<td>2</td>
+<td>4</td>
+<td>numerOfEntries</td>
+<td>int32</td>
+<td>
+The number of values following</td>
+</tr>
+</tbody>
+</table>
+<p>
+After the <span class="objectName">numberOfEntries</span> field the actual strings are encoded. So the following structure is repeated:
+</p>
+<table class="dcm_simple dcm_structure"><colgroup>
+<col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Index</th>
+<th>Length</th>
+<th>Name</th>
+<th>Type</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td>0</td>
+<td>4</td>
+<td>stringDataSize</td>
+<td>int32</td>
+<td>
+The number of string bytes following</td>
+</tr>
+<tr>
+<td>4</td>
+<td>stringDataSize</td>
+<td>value</td>
+<td>byte</td>
+<td>
+The string encoded as a UTF-8 string without null byte termination</td>
+</tr>
+</tbody>
+</table>
+<div id="section_5.3.7" class="heading level_3"><span class="number">5.3.7</span><span class="title">Enum</span></div>
+<p>Enums are supposed to have a maximum number of 16 choices and do have a numeric ordinal value.</p>
+<p>If the field is specified as OPTIONAL or REQUIRED:</p>
+<table class="dcm_simple dcm_structure"><colgroup>
+<col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Index</th>
+<th>Length</th>
+<th>Name</th>
+<th>Type</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td>0</td>
+<td>1</td>
+<td>fieldNumber</td>
+<td>byte</td>
+<td>
+The field number</td>
+</tr>
+<tr>
+<td>1</td>
+<td>1</td>
+<td>typeId</td>
+<td>byte</td>
+<td>
+TYPE_ENUM</td>
+</tr>
+<tr>
+<td>2</td>
+<td>1</td>
+<td>value</td>
+<td>byte</td>
+<td>
+The ordinal number of the enum</td>
+</tr>
+</tbody>
+</table>
+<p>If the field is specified as ORDERED:</p>
+<table class="dcm_simple dcm_structure"><colgroup>
+<col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Index</th>
+<th>Length</th>
+<th>Name</th>
+<th>Type</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td>0</td>
+<td>1</td>
+<td>fieldNumber</td>
+<td>byte</td>
+<td>
+The field number</td>
+</tr>
+<tr>
+<td>1</td>
+<td>1</td>
+<td>typeId</td>
+<td>byte</td>
+<td>
+TYPE_ENUM_LIST</td>
+</tr>
+<tr>
+<td>2</td>
+<td>4</td>
+<td>numerOfEntries</td>
+<td>int32</td>
+<td>
+The number of values following</td>
+</tr>
+<tr>
+<td>6</td>
+<td>…</td>
+<td>value</td>
+<td>byte[]</td>
+<td>
+The ordinal values of the enum</td>
+</tr>
+</tbody>
+</table>
+<p>If the field is specified as UNIQUE:</p>
+<table class="dcm_simple dcm_structure"><colgroup>
+<col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Index</th>
+<th>Length</th>
+<th>Name</th>
+<th>Type</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td>0</td>
+<td>1</td>
+<td>fieldNumber</td>
+<td>byte</td>
+<td>
+The field number</td>
+</tr>
+<tr>
+<td>1</td>
+<td>1</td>
+<td>typeId</td>
+<td>byte</td>
+<td>
+TYPE_ENUM_SET</td>
+</tr>
+<tr>
+<td>2</td>
+<td>4</td>
+<td>numerOfEntries</td>
+<td>int32</td>
+<td>
+The number of values following</td>
+</tr>
+<tr>
+<td>6</td>
+<td>…</td>
+<td>value</td>
+<td>uint16</td>
+<td>
+A bit encoded of the enum values contained. If the enum with the ordinal 3 and 5 are contained in the set the value would be 0x14 since bits 3 and 5 are high.</td>
+</tr>
+</tbody>
+</table>
+<div id="section_5.3.8" class="heading level_3"><span class="number">5.3.8</span><span class="title">Properties map</span></div>
+<p>If the field is specified as OPTIONAL or REQUIRED:</p>
+<table class="dcm_simple dcm_structure"><colgroup>
+<col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Index</th>
+<th>Length</th>
+<th>Name</th>
+<th>Type</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td>0</td>
+<td>1</td>
+<td>fieldNumber</td>
+<td>byte</td>
+<td>
+The field number</td>
+</tr>
+<tr>
+<td>1</td>
+<td>1</td>
+<td>typeId</td>
+<td>byte</td>
+<td>
+TYPE_PROPERTIES</td>
+</tr>
+<tr>
+<td>2</td>
+<td>…</td>
+<td>value</td>
+<td>PropertyEntry</td>
+<td>
+The value</td>
+</tr>
+</tbody>
+</table>
+<p>If the field is specified as ORDERED or UNIQUE:</p>
+<table class="dcm_simple dcm_structure"><colgroup>
+<col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Index</th>
+<th>Length</th>
+<th>Name</th>
+<th>Type</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td>0</td>
+<td>1</td>
+<td>fieldNumber</td>
+<td>byte</td>
+<td>
+The field number</td>
+</tr>
+<tr>
+<td>1</td>
+<td>1</td>
+<td>typeId</td>
+<td>byte</td>
+<td>
+TYPE_PROPERTIES_LIST</td>
+</tr>
+<tr>
+<td>2</td>
+<td>4</td>
+<td>numerOfEntries</td>
+<td>int32</td>
+<td>
+The number of values following</td>
+</tr>
+<tr>
+<td>6</td>
+<td>…</td>
+<td>value</td>
+<td>PropertyEntry[]</td>
+<td>
+The values</td>
+</tr>
+</tbody>
+</table>
+<p>Each <span class="objectName">PropertyEntry</span> is encoded as:</p>
+<table class="dcm_simple dcm_structure"><colgroup>
+<col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Index</th>
+<th>Length</th>
+<th>Name</th>
+<th>Type</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td>0</td>
+<td>4</td>
+<td>keyStringSize</td>
+<td>int32</td>
+<td>
+The number of string byte for following string</td>
+</tr>
+<tr>
+<td>4</td>
+<td>keyStringSize</td>
+<td>keyStringData</td>
+<td>byte[]</td>
+<td>
+The key value. The string encoded as a UTF-8 string without null byte termination</td>
+</tr>
+<tr>
+<td>4 + keyStringSize</td>
+<td>4</td>
+<td>valueStringSize</td>
+<td>int32</td>
+<td>
+The number of string byte for following string</td>
+</tr>
+<tr>
+<td>8 + keyStringSize</td>
+<td>valueStringSize</td>
+<td>valueStringData</td>
+<td>byte[]</td>
+<td>
+The value assigned to the key. The string encoded as a UTF-8 string without null byte termination</td>
+</tr>
+</tbody>
+</table>
+<div id="section_5.3.9" class="heading level_3"><span class="number">5.3.9</span><span class="title">Variant</span></div>
+<p>If the field is specified as OPTIONAL or REQUIRED:</p>
+<table class="dcm_simple dcm_structure"><colgroup>
+<col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Index</th>
+<th>Length</th>
+<th>Name</th>
+<th>Type</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td>0</td>
+<td>1</td>
+<td>fieldNumber</td>
+<td>byte</td>
+<td>
+The field number</td>
+</tr>
+<tr>
+<td>1</td>
+<td>1</td>
+<td>typeId</td>
+<td>byte</td>
+<td>
+TYPE_VARIANT</td>
+</tr>
+<tr>
+<td>2</td>
+<td>…</td>
+<td>value</td>
+<td>VariantEntry</td>
+<td>
+The value</td>
+</tr>
+</tbody>
+</table>
+<p>If the field is specified as ORDERED or UNIQUE:</p>
+<table class="dcm_simple dcm_structure"><colgroup>
+<col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Index</th>
+<th>Length</th>
+<th>Name</th>
+<th>Type</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td>0</td>
+<td>1</td>
+<td>fieldNumber</td>
+<td>byte</td>
+<td>
+The field number</td>
+</tr>
+<tr>
+<td>1</td>
+<td>1</td>
+<td>typeId</td>
+<td>byte</td>
+<td>
+TYPE_VARIANT_LIST</td>
+</tr>
+<tr>
+<td>2</td>
+<td>4</td>
+<td>numerOfEntries</td>
+<td>int32</td>
+<td>
+The number of values following</td>
+</tr>
+<tr>
+<td>6</td>
+<td>…</td>
+<td>value</td>
+<td>VariantEntry[]</td>
+<td>
+The values</td>
+</tr>
+</tbody>
+</table>
+<p>Each <span class="objectName">VariantEntry</span> is encoded as described in <q>Variant</q>.</p>
+<div id="section_5.3.10" class="heading level_3"><span class="number">5.3.10</span><span class="title">Variant Map</span></div>
+<p>If the field is specified as OPTIONAL or REQUIRED:</p>
+<table class="dcm_simple dcm_structure"><colgroup>
+<col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Index</th>
+<th>Length</th>
+<th>Name</th>
+<th>Type</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td>0</td>
+<td>1</td>
+<td>fieldNumber</td>
+<td>byte</td>
+<td>
+The field number</td>
+</tr>
+<tr>
+<td>1</td>
+<td>1</td>
+<td>typeId</td>
+<td>byte</td>
+<td>
+TYPE_VARIANT_MAP</td>
+</tr>
+<tr>
+<td>2</td>
+<td>…</td>
+<td>value</td>
+<td>VariantMapEntry</td>
+<td>
+The value</td>
+</tr>
+</tbody>
+</table>
+<p>If the field is specified as ORDERED or UNIQUE:</p>
+<table class="dcm_simple dcm_structure"><colgroup>
+<col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Index</th>
+<th>Length</th>
+<th>Name</th>
+<th>Type</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td>0</td>
+<td>1</td>
+<td>fieldNumber</td>
+<td>byte</td>
+<td>
+The field number</td>
+</tr>
+<tr>
+<td>1</td>
+<td>1</td>
+<td>typeId</td>
+<td>byte</td>
+<td>
+TYPE_VARIANT_MAP_LIST</td>
+</tr>
+<tr>
+<td>2</td>
+<td>4</td>
+<td>numerOfEntries</td>
+<td>int32</td>
+<td>
+The number of values following</td>
+</tr>
+<tr>
+<td>6</td>
+<td>…</td>
+<td>value</td>
+<td>VariantMapEntry[]</td>
+<td>
+The values</td>
+</tr>
+</tbody>
+</table>
+<p>Each <span class="objectName">VariantMapEntry</span> is encoded as:</p>
+<table class="dcm_simple dcm_structure"><colgroup>
+<col class="dcm_left" />
+</colgroup>
+<thead><tr>
+<th>Index</th>
+<th>Length</th>
+<th>Name</th>
+<th>Type</th>
+<th>Description</th>
+</tr></thead>
+<tbody>
+<tr>
+<td>0</td>
+<td>4</td>
+<td>keyStringSize</td>
+<td>int32</td>
+<td>
+The number of string byte for following string</td>
+</tr>
+<tr>
+<td>4</td>
+<td>keyStringSize</td>
+<td>keyStringData</td>
+<td>byte[]</td>
+<td>
+The key value. The string encoded as a UTF-8 string without null byte termination</td>
+</tr>
+<tr>
+<td>4 + keyStringSize</td>
+<td>…</td>
+<td>value</td>
+<td>VariantEntry</td>
+<td>
+The variant value</td>
+</tr>
+</tbody>
+</table>
+<p>Each <span class="objectName">VariantEntry</span> is encoded as described in <q>Variant</q>.</p>
+<div id="section_5.4" class="heading level_2"><span class="number">5.4</span><span class="title">Values</span></div>
+<table class="dcm_simple"><colgroup>
+<col class="dcm_left" />
+<col class="dcm_right" />
+</colgroup>
+<thead><tr>
+<th>Type ID</th>
+<th>Numeric hex value</th>
+</tr></thead>
+<tbody>
+<tr>
+<td class="dcm_left">TYPE_NULL</td>
+<td class="dcm_right">0x00</td>
+</tr>
+<tr>
+<td class="dcm_left">TYPE_STRING</td>
+<td class="dcm_right">0x01</td>
+</tr>
+<tr>
+<td class="dcm_left">TYPE_STRING_LIST</td>
+<td class="dcm_right">0x11</td>
+</tr>
+<tr>
+<td class="dcm_left">TYPE_LONG</td>
+<td class="dcm_right">0x02</td>
+</tr>
+<tr>
+<td class="dcm_left">TYPE_LONG_LIST</td>
+<td class="dcm_right">0x12</td>
+</tr>
+<tr>
+<td class="dcm_left">TYPE_INT</td>
+<td class="dcm_right">0x03</td>
+</tr>
+<tr>
+<td class="dcm_left">TYPE_INT_LIST</td>
+<td class="dcm_right">0x13</td>
+</tr>
+<tr>
+<td class="dcm_left">TYPE_BOOLEAN</td>
+<td class="dcm_right">0x04</td>
+</tr>
+<tr>
+<td class="dcm_left">TYPE_BOOLEAN_LIST</td>
+<td class="dcm_right">0x14</td>
+</tr>
+<tr>
+<td class="dcm_left">TYPE_DOUBLE</td>
+<td class="dcm_right">0x05</td>
+</tr>
+<tr>
+<td class="dcm_left">TYPE_DOUBLE_LIST</td>
+<td class="dcm_right">0x15</td>
+</tr>
+<tr>
+<td class="dcm_left">TYPE_VARIANT</td>
+<td class="dcm_right">0x06</td>
+</tr>
+<tr>
+<td class="dcm_left">TYPE_VARIANT_LIST</td>
+<td class="dcm_right">0x16</td>
+</tr>
+<tr>
+<td class="dcm_left">TYPE_VARIANT_MAP</td>
+<td class="dcm_right">0x07</td>
+</tr>
+<tr>
+<td class="dcm_left">TYPE_VARIANT_MAP_LIST</td>
+<td class="dcm_right">0x17</td>
+</tr>
+<tr>
+<td class="dcm_left">TYPE_PROPERTIES</td>
+<td class="dcm_right">0x08</td>
+</tr>
+<tr>
+<td class="dcm_left">TYPE_PROPERTIES_LIST</td>
+<td class="dcm_right">0x18</td>
+</tr>
+<tr>
+<td class="dcm_left">TYPE_STRUCTURE</td>
+<td class="dcm_right">0x09</td>
+</tr>
+<tr>
+<td class="dcm_left">TYPE_STRUCTURE_LIST</td>
+<td class="dcm_right">0x19</td>
+</tr>
+<tr>
+<td class="dcm_left">TYPE_ENUM</td>
+<td class="dcm_right">0x0A</td>
+</tr>
+<tr>
+<td class="dcm_left">TYPE_ENUM_LIST</td>
+<td class="dcm_right">0x1A</td>
 </tr>
 <tr>
-<td class="dcm_left">6</td>
-<td class="dcm_left">Data</td>
-<td class="dcm_left">bytes</td>
-<td class="dcm_left">Message payload, must be encoded/decoded depending on the mesage type.</td>
+<td class="dcm_left">TYPE_ENUM_SET</td>
+<td class="dcm_right">0x2A</td>
 </tr>
 </tbody>
 </table>
-<div id="section_3" class="heading level_1"><span class="number">3</span><span class="title">Appendices</span></div>
-<div id="section_license" class="heading level_2"><span class="number">3.I</span><span class="title">GNU Free Documentation License</span></div>
+<div id="section_6" class="heading level_1"><span class="number">6</span><span class="title">Appendices</span></div>
+<div id="section_license" class="heading level_2"><span class="number">6.I</span><span class="title">GNU Free Documentation License</span></div>
 <pre>
 
                 GNU Free Documentation License

org.openscada.documentation/protocol/book/styles/content.css

 }
 
 table.dcm_simple {
+	caption-side: bottom;
 }
 
 .dcm_left {
 	text-align: left;
-	
 }
 
 .dcm_center {

org.openscada.documentation/protocol/content/about.content

+<?xml version="1.0" encoding="UTF-8"?>
+<content:fragment xmlns:content="urn:openscada:doc:content">
+
+<content:p>
+This document describes the internal openSCADA protocols.
+</content:p>
+
+<content:p>
+The reader of this document should be familiar with TCP/IP based network 
+communication.
+</content:p>
+
+</content:fragment>

org.openscada.documentation/protocol/content/introduction.content

-<?xml version="1.0" encoding="UTF-8"?>
-<content:fragment xmlns:content="urn:openscada:doc:content">
-
-<content:p>
-This document describes the internal openSCADA protocols.
-</content:p>
-
-<content:p>
-The reader of this document should be familiar with TCP/IP based network 
-communication.
-</content:p>
-
-</content:fragment>

org.openscada.documentation/protocol/content/ngp/01_introduction.content

+<?xml version="1.0" encoding="UTF-8"?>
+<content:fragment xmlns:content="urn:openscada:doc:content">
+
+<content:section content:title="Introduction">
+
+<content:p>
+The <content:q>NPG</content:q> protocol (<content:q>next generation protocol</content:q>) is the
+successor of the <content:q>GMPP/NET</content:q> protocol of openSCADA. it was created in order
+to fix some performance issues and make it easier to extend the protocol. 
+</content:p>
+
+<content:p>
+NGP is a plain Client/Server TCP/IP protocol. The server side is also the TCP server. So an
+DA server (aka <content:q>Hive</content:q>, <content:q>Driver Module</content:q>) is the
+TCP server.
+</content:p>
+
+<content:p>
+The basic idea of the protocol is that after a common ground for passing messages was
+established between the client and the server each side may send messages (structures)
+to the other side at will. The messages are transmitted complete and in order. The encoding
+of the messages it not relevant. Messages consist of a limited number of primive datatypes
+and can build structures without references. A message does not have a direct reply. A
+reply is just another message which might of course contain some id it refers to. But this is
+not part of the protocol but part of the message.
+</content:p>
+
+<content:p>
+The protocol is split into two different layers. The first layer is the
+framing layer which act as a message channel. The second layer uses the message channel
+to pass messages betwen server and client. So after the TCP connection is established
+the message channel will perform a handshake and configure the connection parameters
+(like encryption and compression). After the handshake was performed <content:q>data</content:q>
+messages can be exchanged between the two communication parties. The content of these
+messages is irrelevant for the message channel and will be interpreted by the second layer.
+</content:p>
+
+<content:p>
+The second layer gets configured during the message channel handshake and supports different
+types of codec filters/serializers. Which type is used is decided during the handshake phase.
+After the codec has been chosen it cannot be changed anymore.
+</content:p>
+
+<content:p>
+The result of the second layer is a <content:q>stream</content:q> of interpreted
+messages which make up the real data of the openSCADA protocol that is transmitted.
+</content:p>
+
+</content:section>
+
+</content:fragment>

org.openscada.documentation/protocol/content/ngp/01_overview.content

-<?xml version="1.0" encoding="UTF-8"?>
-<content:fragment xmlns:content="urn:openscada:doc:content">
-
-<content:p>
-The <content:q>NPG</content:q> protocol (<content:q>next generation protocol</content:q>) is the
-successor of the <content:q>GMPP/NET</content:q> protocol of openSCADA. it was created in order
-to fix some performance issues and make it easier to extend the protocol. 
-</content:p>
-
-<content:section content:title="Overview">
-
-<content:p>
-NGP is a plain Client/Server TCP/IP protocol. The server side is also the TCP server. So an
-DA server (aka <content:q>Hive</content:q>, <content:q>Driver Module</content:q>) is the
-TCP server.
-</content:p>
-
-<content:p>
-The basic idea of the protocol is that after a common ground for passing messages was
-established between the client and the server each side may send messages (structures)
-to the other side at will. The messages are transmitted complete and in order. The encoding
-of the messages it not relevant. Messages consist of a limited number of primive datatypes
-and can build structures without references. A message does not have a direct reply. A
-reply is just another message which might of course contain some id it refers to. But this is
-not part of the protocol but part of the message.
-</content:p>
-
-<content:p>
-The protocol is split into two different layers. The first layer is the
-framing layer which act as a message channel. The second layer uses the message channel
-to pass messages betwen server and client. So after the TCP connection is established
-the message channel will perform a handshake and configure the connection parameters
-(like encryption and compression). After the handshake was performed <content:q>data</content:q>
-messages can be exchanged between the two communication parties. The content of these
-messages is irrelevant for the message channel and will be interpreted by the second layer.
-</content:p>
-
-<content:p>
-The second layer gets configured during the message channel handshake and supports different
-types of codec filters/serializers. Which type is used is decided during the handshake phase.
-After the codec has been chosen it cannot be changed anymore.
-</content:p>
-
-<content:p>
-The result of the second layer is a <content:q>stream</content:q> of interpreted
-messages which make up the real data of the openSCADA protocol that is transmitted.
-</content:p>
-
-</content:section>
-
-
-<content:section content:title="Message channel">
-
-<content:section content:title="Message types">
-
-<content:p>
-The message channel sends frames. Frames have a distinct type and encoding. The following frame
-types are defined:
-</content:p>
-
-<content:simpleTable>
-<content:column content:horizontalAlign="LEFT" content:title="Name"/>
-<content:column content:horizontalAlign="LEFT" content:title="Numeric"/>
-<content:column content:horizontalAlign="LEFT" content:title="Sender"/>
-<content:column content:horizontalAlign="LEFT" content:title="Description"/>
-
-<content:row>
-<content:cell>HELLO</content:cell><content:cell>0</content:cell><content:cell>Client</content:cell>
-<content:cell>Sent by the client to initiate the communication. Must only be sent once, as
-first message</content:cell>
-</content:row>
-
-<content:row>
-<content:cell>MESSAGE</content:cell><content:cell>1</content:cell><content:cell>Any</content:cell>
-<content:cell>A message containing data. Must only be sent after the handshake
-was completed successfully.</content:cell>
-</content:row>
-
-<content:row>
-<content:cell>ACCEPT</content:cell><content:cell>2</content:cell><content:cell>Server</content:cell>
-<content:cell>Sent by the server after a HELLO message was received and confirming the
-successful handshake. Must only be sent once.</content:cell>
-</content:row>
-
-<content:row>
-<content:cell>CLOSE</content:cell><content:cell>3</content:cell><content:cell>Any</content:cell>
-<content:cell>Sent by either side to provide a reason for the imminent close of the connection.
-This message may be sent only once and must be last message sent. It may also
-be sent directly after the HELLO message was received.</content:cell>
-</content:row>
-
-<content:row>
-<content:cell>START</content:cell><content:cell>4</content:cell><content:cell>Client</content:cell>
-<content:cell>Sent by the client to tell the server that the communication parameters
-of the ACCEPT message have been applied and the handshake is complete. This message must
- be sent once after the ACCEPT message has been received and the communication parameters
- (compression, ssl, …) have been applied by the client.</content:cell>
-</content:row>
-
-<content:row>
-<content:cell>PING</content:cell><content:cell>5</content:cell><content:cell>Any</content:cell>
-<content:cell>Sent by any party after the handshake has been completed to see is the other
-side is still connected. The receiver of the message must respond with a PONG message.</content:cell>
-</content:row>
-
-<content:row>
-<content:cell>PONG</content:cell><content:cell>5</content:cell><content:cell>Any</content:cell>
-<content:cell>Sent exactly once by any party after a PING message was received.</content:cell>
-</content:row>