Simple Open Framing Header

[plemanach]

Hello,

Is this implementation use Simple Open Framing Header ?

Regards,

Patrice

[donmendelson]

Currently, it is only using a message size prefix before the SBE header. I have Simple Open Framing Header listed on the Feature Roadmap in the project wiki. Do you think that feature should be prioritized? (Contributions to this project are welcome!)

[plemanach]

I would participate but I am more of a c# developer :) I think the framing is a key feature just to show that the encoding is plug-gable.

[donmendelson]

Agreed. Framing for inbound messages is already pluggable through

FixpSession.Builder.withMessageFramer(FrameSpliterator frameSpliter)

Two things are needed:

• An implementation of FrameSpliterator for SOFH.
• An equivalent pluggable feature to encode frame header outbound messages.

[donmendelson]

I moved this up in the feature road map to version 1.0.

[plemanach]

Thanks

[donmendelson]

Some ground rules, which should probably make there way into the FIXP spec:

• The send and receive sides are not symmetrical with respect to the SOFH. A FrameSpliterator will work for the receive side, and it can be pluggable as mentioned above. However, a main motivation for using SOFH is to mix encodings on a session. If that is done, only the application would know the encoding it used for a given application message. Therefore, frame header encoding must be done in the application layer, not in the session layer.
• The session layer must encode the frame header for session messages. That can be controlled by a pluggable policy.
• The same framing header must be used for all sessions on a multiplexed transport. There would be no practical way to delimit messages with mixed framing policies.