At the time we are writing this documentation, the Fast is still in its early stage. Not too many people are using it. There are also several non-standard applications around.
The Fast template and encoding decoding are very well designed and documented. However, the Fast Session Control Protocol (SCP 1.1) is not very well defined. The SCP documentation only defines the basic requirement of session control. Lots of features are not included in the SCP 1.1 documentation such as authentication and authorization. Also the template definition exchange only looks good on paper. That's why we would expect a lot of Fast session dialect before the release of the next version of Fast SCP.
In our API design, we leave enough flexibility to allow our Fast implementation work with existing and future Fast applications. That's why we only standardized the API for Fast template operations and the Fast codec (encoder and decoder). We didn't even include a "FastSession" into our standard library. Instead, we provided a "reference" implementation of FastSession and released it as a sample with ful source code. Our reference implementation of "FastSession" is a Fast SCP 1.1 session, which can be used either as a sample or as a reference for users to implement their own Fast sessions.
FastSessionContext is created with two parameters, a FastSchema that represents the application fast message templates and a FastSchema that represents the session control message templates.
FastSessionContext provides all operations required to maintain a Fast session defined in both the Fast Specification 1.x.1 and Fast SCP 1.1 (either message stream based or block based).
FastSessionContext is a state machine. It keeps track of the value dictionary for both encoder and decoder. One FastSessionContext can be used by one bi-directional Fast session in order to handle both message encoding and message decoding.
One FastSessionContext should be bound with one FIX session and the life cycle of FastSessionContext should be the same as the associated Fast session. It is recommended that a new FastSessionContext be created for each new Fast session.
Dynamic Message Definition Exchange
Dynamic message definition exchange is the tricky part. Once a dynamic message definition is accepted, the corresponding dictionary entry has to be created and initialized.
At this time we don't support clearing the dynamic message definition in FastSessionContext API. That feature might be added in future releases.
If dynamic message definiton is supported and the Fast session is accidentally disconnected, the re-established connection should be treated as a new fast session because the dynamic template definition exchange should be cleared. In that case a new instance of FastSessionContext must be created for the "new session".