You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SBE messages need framing when used with protocols that do not preserve
8
-
message boundaries, such as when they are transmitted on a streaming
9
-
session protocol or are persisted in storage. Be aware that framing
10
-
features may or may not be encoded in SBE.
7
+
SBE messages have no defined message delimiter. Version 2.0 of SBE makes it possible to walk the elements of a message to determine its limit, even when the message has been extended. Nevertheless, since internal framing depends on a correct starting point and not encountering malformed messages, it may be desirable to use an external framing protocol when used with transports that do not preserve message boundaries, such as when they are transmitted on a streaming
8
+
session protocol or when persisting messages in storage.
11
9
12
10
### Simple Open Framing Header
13
11
@@ -73,6 +71,10 @@ The fields of the SBE message header are:
73
71
-**Schema version** - the version of the message schema in which the
74
72
message is defined
75
73
74
+
-**Group count** - the number of repeating groups in the root level of the message
75
+
76
+
-**Variable-length field count** - the number of variable-length fields in the root level of the message
77
+
76
78
Block length is specified in a message schema, but it is also serialized
77
79
on the wire. By default, block length is set to the sum of the sizes of
78
80
body fields in the message. However, it may be increased to force
Copy file name to clipboardExpand all lines: v1-0-STANDARD/doc/05SchemaExtensionMechanism.md
+6-13Lines changed: 6 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -22,12 +22,9 @@ Compatibility is only ensured under these conditions:
22
22
23
23
- Existing fields cannot change data type or move within a message.
24
24
25
-
- A repeating group may be added, but only after existing groups and
26
-
if there are no subsequent variable data elements at the end of the
27
-
message.
25
+
- A repeating group may be added after existing groups at the root level or nested within another repeating group.
28
26
29
-
- A variable data element may be added, but only after existing groups
30
-
and data.
27
+
- A variable-length data field may be added after existing variable-length data at the root level or within a repeating group.
31
28
32
29
- Message header encoding cannot change.
33
30
@@ -92,14 +89,6 @@ migration to replacement message layouts.
92
89
Wire format features for extension
93
90
----------------------------------
94
91
95
-
### Message size
96
-
97
-
It is assumed that a either message boundaries are delimited by a
98
-
transport or session protocol header conveys the size of the whole
99
-
message. See section 3.1 above. This enables a consumer to properly
100
-
frame messages even when the message has been lengthened in a later
101
-
version of the schema.
102
-
103
92
### Block size
104
93
105
94
The length of the root level of the message is sent on the wire in the
@@ -113,6 +102,10 @@ does not break parsing of earlier fields.
113
102
Likewise, block size of a repeating group is conveyed in the NumInGroup
114
103
encoding.
115
104
105
+
### Number of repeating groups and variable data
106
+
107
+
Message headers and repeating group dimensions carry a count of the number of repeating groups and a count of variable-length data fields on the wire. This supports a walk by a decoder of all the elements of a message, even when the decoder was built with an older version of a schema. As for added fixed-length fields, new repeating groups cannot be interpreted by the decoder, but it still can process the ones it knows, and it can correctly reach the end of a message.
| 2 | Schema extension is vague in terms of what compatibility means | 5
12
-
| 3 | Extensibility of the Template ID | 5
13
-
| 6 | Limiting maximum occurences of repeating group | 3
14
-
| 8 | blockLength for repeating groups of variable length | 3
15
-
| 11 | Offsets within composite types | 4
16
-
| 12 | Composites reusing other types | 4
4
+
These are the changes made since SBE version 1.0.
17
5
18
-
Release Candidate 3
6
+
SBE version 2.0 Release Candidate 1
19
7
-------------------
8
+
These issues were resolved and accepted for version 2.0 Release Candidate 1. See [issues](https://github.com/FIXTradingCommunity/fix-simple-binary-encoding/issues) and [pull requests](https://github.com/FIXTradingCommunity/fix-simple-binary-encoding/pulls) in GitHub for details and changes.
20
9
21
-
This is a summary of document changes to Release Candidate 3 from RC2.
22
-
Changes in this release were intended only as clarifications or to add
23
-
capabilities. Message schemas that conformed to the RC2 specification
24
-
should still conform to the RC3 wire format.
25
-
26
-
**Section 1**
27
-
28
-
References section expanded.
29
-
30
-
**Section 2**
31
-
32
-
- Statement added that non-FIX data types should not carry a
33
-
semanticType attribute in a message schema.
34
-
35
-
- String encoding section split into two sections for strings (text
36
-
fields) and data (non-character data) to clarify the distinction.
37
-
Both text and non-text can be either fixed-length `<field>` or
38
-
variable-length `<data>`.
39
-
40
-
- Timestamp encoding enhanced to allow time unit to either be
41
-
specified as a constant in a message schema or to be serialized on
42
-
the wire.
43
-
44
-
**Section 3**
45
-
46
-
Message structure is enhanced to allow variable-length `<data>` elements
47
-
within a repeating group entry.
48
-
49
-
**Section 4**
50
-
51
-
Message schema XSD updated to support `<data>` in repeating groups and
52
-
for various other refinements
53
-
54
-
**Section 5**
55
-
56
-
- Statements added to say whole repeating groups or variable data may
57
-
be added to a message without breaking compatibility so long as the
58
-
added elements are at the end of a message.
59
-
60
-
- Added deprecated schema attribute to mark obsolete elements.
61
-
62
-
**Section 6**
63
-
64
-
No change
65
-
66
-
**Section 7**
67
-
68
-
Examples updated to use Simple Open Framing Header.
SBE messages need framing when used with protocols that do not preserve
8
-
message boundaries, such as when they are transmitted on a streaming
9
-
session protocol or are persisted in storage. Be aware that framing
10
-
features may or may not be encoded in SBE.
7
+
SBE messages have no defined message delimiter. Version 2.0 of SBE makes it possible to walk the elements of a message to determine its limit, even when the message has been extended. Nevertheless, since internal framing depends on a correct starting point and not encountering malformed messages, it may be desirable to use an external framing protocol when used with transports that do not preserve message boundaries, such as when they are transmitted on a streaming
8
+
session protocol or when persisting messages in storage.
11
9
12
10
### Simple Open Framing Header
13
11
@@ -73,6 +71,10 @@ The fields of the SBE message header are:
73
71
-**Schema version** - the version of the message schema in which the
74
72
message is defined
75
73
74
+
-**Group count** - the number of repeating groups in the root level of the message
75
+
76
+
-**Variable-length field count** - the number of variable-length fields in the root level of the message
77
+
76
78
Block length is specified in a message schema, but it is also serialized
77
79
on the wire. By default, block length is set to the sum of the sizes of
78
80
body fields in the message. However, it may be increased to force
0 commit comments