What are CF Protocols, Binders, and Flows
This topic describes the concepts of Communications Framework (CF) Protocols,Binders and Flows in the Communications Framework.
In the Communications Architecture each Layer requires the participation of several communications components; namely the Tier Manager, MCPR, CPR, SCPR and the components. The name given to the Data Flow components is a Communications Framework Protocol (CF Protocol).
A CF Protocol is a collection of components on the Data Plane, most importantly the Flow and the Binder(s). The Flow is a Node and communicates with the SCPR that caused it to be started, using the asynchronous Message Transport mechanism. Each Flow has one or more Binders which connect the Flow to the layer above.
CF Protocol components
A CF Protocol is constructed of two main components:
Flow - a single conversation with a remote peer. There can be multiple Flows in a CF Protocol to handle multiple concurrent conversations through the same instance of the CF Protocol.
Binder - A Binder handles the interface between the current Flow and the Layer above. A Binder connects two CF Protocols together so that they can communicate data and sometimes commands. A Flow can have more than one Binder if it needs to connect to more than one Flow in the Layer above.
A Protocol Binder is the binding point for de-multiplexed incoming data but provides no flow control, data will be lost if the layer above is not ready to process it.
A Session Binder handles flow control by contacting the Layer above to say data is available, and waits for the CF Protocol of the Layer above to request the data.
Flow
A Flow is an instance of a class which represents a single conversation with a remote peer.
There may be many active Flows in a CF Protocol to represent many concurrent conversations through the same instance of the CF Protocol.
A Flow is a Stack Node created and controlled by one SCPR.
Configuration data for the Flow is provisioned directly by the SCPR and usually originates from the MCPR.
Since a Flow handles message exchange with the corresponding SCPR asynchronously, a Flow is always a state machine. State transitions are mostly triggered by exchange of different message types with the remote peer. State transitions may also be triggered by other mechanisms, such as timeouts, that require active objects within the Flow. A Flow is created by a Factory.
The Flow can de-multiplex the inbound, though it is up to the specific Flow to have appropriate code to do the de-multiplexing. De-multiplexing could be performed based on address information, port information, protocol specific session, source identifier or other data. De-multiplexing passes data to specific Flows, via individual Protocol Binders, to higher level CF Protocols which can also de-multiplex the data further. If there is no de-multiplexing then the layer above does not have to bind a protocol interface as a data receiver. An example would be an IP Flow, which may contain IPv4 and IPv6 packets and would have separate Protocl Binders for each version.
Each Flow must serve the following messages:
TBindTo - tells the Flow which lower Flow to bind to
TProvisionConfig - carries a configuration object
TStartFlow - starts the Flow
TStopFlow - stops the Flow
TDestroy - instructs the Flow to delete itself
TStateChange - the Flow should send this whenever it wants to inform the control side of its state change
Binder
The Binder is split into two parts:
Binder Control - used by the upper layer to set up the binding with the lower layer.
Binder - the actual binding between two Layers so that data can be sent and received. Again there are two types of Binder, Protocol Binder and Session Binder. It is common for a particular CF Protocol to only support one kind of Binder, Session or Protocol.
There will be CF Protocols where it will be a good design to have a Protocol Binder for data, and to use a Session Binder for control messages. These will usually be separate Flows.
A Protocol Binder is used by the Flow as the link to the next higher CF Protocol for inbound data.
A Protocol Binder only communicates with the Flow and should never communicate with an SCPR. Any design that would require the Protocol Binder to communicate with the SCPR should be redesigned.
Protocol Binders are most commonly used for lower-level protocols (nearer the hardware) rather than the higher-level Link layer protocols.
A Session Binder offers much richer functionality than a Protocol Binder as it is mostly used by higher level protocols (closer to application space) that are more complex than the lower level ones (closer to hardware). A Session Binder operates independently of the protocol of the next Layer above with which it connects, as opposed to the Protocol Binder which is specific for a particular protocol in the Layer above. A Session Binder may offer functionality that is supported by only some of the protocols using that binder. For example a Session Binder may provide flow control on the data, while a Protocol Binder will pass the data upwards immediately and if the Layer above is not able to accept the data it will be discarded.