Occasionally, parties communicating via JSTP want to share either large files or heavy content that is intended to keep on streaming over time and should be optimized for network performance. Examples of this are video streaming, huge file transfers and remote desktop applications. The Regular Morphology load footprint is quite large for this special occasions and should be upgraded to a "bare metal" configuration.
Streaming Morphology is the answer to this need. On a Streaming Morphology, the first Dispatch varies in that instead of a Body Header, it features a formalized Stream Header describing the stream's characteristics, and is followed by an arbitrarily large series of pieces that consist mainly of a piece identifier and a payload. For example:
On the Stream Start Dispatch, notice the body header is missing. Instead, there is a stream header, with an id. The id is the Stream ID, and will be used by the subsequent pieces to identify themselves as part of the Stream. It is recommended to use some kind of UUID to minimize the chance of collisions.
The Stream Header accepts several other fields:
quantity: The total amount of pieces to be sent. In non-streaming contexts, such as when sending large files, this allow receivers to check for consistency and request any missing pieces.
start: The index of the first piece to be sent in this Streaming Session. This is useful for requesting parts of files from multiple sharding servers, and for receivers to understand that pieces starting from above 0 do not indicate that some pieces went missing.
On the Piece Dispatches, the only "header" is the Stream ID, and the field of the Stream ID header is the Piece ID and the actual Piece Body.
For now, there is no specification as to whether or not this ID has to be numerical, or even actually ordered. Some applications may benefit from using UNIX timestamps as IDs for the pieces. This means that actual consistency checking is application and not protocol level and JSTP Engine have nor the responsibility neither the means to check for consistency in streams.
Neither is specified the format for the payload, although we think that base 64 is likely to be used for binary data.
Occasionally, parties communicating via JSTP want to share either large files or heavy content that is intended to keep on streaming over time and should be optimized for network performance. Examples of this are video streaming, huge file transfers and remote desktop applications. The Regular Morphology load footprint is quite large for this special occasions and should be upgraded to a "bare metal" configuration.
Streaming Morphology is the answer to this need. On a Streaming Morphology, the first Dispatch varies in that instead of a Body Header, it features a formalized Stream Header describing the stream's characteristics, and is followed by an arbitrarily large series of pieces that consist mainly of a piece identifier and a payload. For example:
Stream Start Dispatch
Piece Dispatches
Some explaining is due
On the Stream Start Dispatch, notice the
bodyheader is missing. Instead, there is astreamheader, with anid. The id is the Stream ID, and will be used by the subsequent pieces to identify themselves as part of the Stream. It is recommended to use some kind of UUID to minimize the chance of collisions.The Stream Header accepts several other fields:
On the Piece Dispatches, the only "header" is the Stream ID, and the field of the Stream ID header is the Piece ID and the actual Piece Body.
For now, there is no specification as to whether or not this ID has to be numerical, or even actually ordered. Some applications may benefit from using UNIX timestamps as IDs for the pieces. This means that actual consistency checking is application and not protocol level and JSTP Engine have nor the responsibility neither the means to check for consistency in streams.
Neither is specified the format for the payload, although we think that base 64 is likely to be used for binary data.