--- a/Symbian3/SDK/Source/GUID-F8069628-BD32-535C-963A-A1CF8172E275.dita	Wed Mar 31 11:11:55 2010 +0100
+++ b/Symbian3/SDK/Source/GUID-F8069628-BD32-535C-963A-A1CF8172E275.dita	Fri Jun 11 12:39:03 2010 +0100
@@ -1,16 +1,16 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
-<!-- This component and the accompanying materials are made available under the terms of the License 
-"Eclipse Public License v1.0" which accompanies this distribution, 
-and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
-<!-- Initial Contributors:
-    Nokia Corporation - initial contribution.
-Contributors: 
--->
-<!DOCTYPE concept
-  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
-<concept xml:lang="en" id="GUID-F8069628-BD32-535C-963A-A1CF8172E275"><title>What are CF Protocols, Binders, and Flows</title><shortdesc>This topic describes the concepts of <i>Communications Framework (CF) Protocols</i>,<i>Binders</i> and <i>Flows</i> in the Communications Framework. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody><p>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 <b>Communications Framework Protocol</b> (CF Protocol). </p> <fig id="GUID-293BE7D5-9C9D-5A17-9C61-5FA19B06490C"><title>
-          Figure 1 - A CF Protocol in the Layered Comms Stack 
-        </title> <image href="GUID-9FB82D95-F110-5D42-B39E-BCFAE574E18F_d0e84040_href.png" placement="inline"/></fig> <p>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. </p> <section><title>CF Protocol components</title> <fig id="GUID-171654F9-312C-547C-A886-E16A9DB21040"><title>
-             Components of a CF Protocol 
-          </title> <image href="GUID-E63899B3-8EA8-5EF7-982E-EC161B3A4794_d0e84053_href.png" placement="inline"/></fig> <p>A CF Protocol is constructed of two main components: </p> <ul><li id="GUID-B9E64AE4-CC30-5085-82D1-938C397A4FD3"><p> <b>Flow</b> - 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. </p> </li> <li id="GUID-6A394EF2-EFD4-5885-BE40-A62784A85E2B"><p> <b>Binder</b> - 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. </p> <p>A <b>Protocol Binder</b> 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. </p> <p>A <b>Session Binder</b> 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. </p> </li> </ul> </section> <section id="GUID-832AD765-692C-56BE-92AC-AF8AEFB69413"><title>Flow</title> <p>A Flow is an instance of a class which represents a single conversation with a remote peer. </p> <p>There may be many active Flows in a CF Protocol to represent many concurrent conversations through the same instance of the CF Protocol. </p> <p>A Flow is a Stack Node created and controlled by one SCPR. </p> <p>Configuration data for the Flow is provisioned directly by the SCPR and usually originates from the MCPR. </p> <p>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. </p> <p>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. </p> <p>Each Flow must serve the following messages: </p> <ul><li id="GUID-CF546C5F-B597-528B-8A7D-3D9AB804291F"><p> <xref href="GUID-413B79AB-EFA4-3C29-842B-F4DFE2C5A87D.dita"><apiname>TBindTo</apiname></xref> - tells the Flow which lower Flow to bind to </p> </li> <li id="GUID-31FDA6FA-251D-5E98-A194-E134EF953311"><p> <xref href="GUID-F2EEF015-3165-32D6-B98C-E77B2BDFDCDF.dita"><apiname>TProvisionConfig</apiname></xref> - carries a configuration object </p> </li> <li id="GUID-B4D38D5B-5537-5882-A7D0-F5A1AEC9E34C"><p> <xref href="GUID-2257D314-72A9-3A2A-9E79-4BCED7AC1045.dita"><apiname>TStartFlow</apiname></xref> - starts the Flow </p> </li> <li id="GUID-3DB58B6B-32E0-5B0A-B8D1-3D6B6CDF41A0"><p> <xref href="GUID-74EDDB44-5E1B-34CF-9678-C7C8811C7D58.dita"><apiname>TStopFlow</apiname></xref> - stops the Flow </p> </li> <li id="GUID-1BAC8A9D-94D6-5E96-BEAE-0EC97537EA16"><p> <xref href="GUID-9E005556-76E5-306B-982C-B2C2BC268EB8.dita"><apiname>TDestroy</apiname></xref> - instructs the Flow to delete itself </p> </li> <li id="GUID-DF01A012-4D45-5670-A62A-91ADA3303A10"><p> <xref href="GUID-B61247EA-48AE-301B-8089-0B5E67B5E04C.dita"><apiname>TStateChange</apiname></xref> - the Flow should send this whenever it wants to inform the control side of its state change </p> </li> </ul> </section> <section id="GUID-B09A95DB-93A8-5D36-BB95-40DA8766E3A0"><title>Binder</title> <p>The Binder is split into two parts: </p> <ul><li id="GUID-261D54B9-E404-5282-A322-A98EC5693DCF"><p> <i>Binder Control</i> - used by the upper layer to set up the binding with the lower layer. </p> </li> <li id="GUID-5D596068-F8A6-564C-A084-82FAB47B2035"><p> <i>Binder</i> - 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. </p> </li> </ul> <p>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. </p> <p id="GUID-C16F3524-AFFE-5E0B-82A7-8EC9B12BA660"><b>Protocol Binder</b> </p> <p>A Protocol Binder is used by the Flow as the link to the next higher CF Protocol for inbound data. </p> <p>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. </p> <p>Protocol Binders are most commonly used for lower-level protocols (nearer the hardware) rather than the higher-level Link layer protocols. </p> <p id="GUID-E6B2C4D3-BE14-53DC-8616-5D3BC2B14686"><b>Session Binder</b> </p> <p> 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. </p> </section> </conbody><related-links><link href="GUID-01029B52-55E0-5598-994F-BB5DE73D37EE.dita"><linktext>Layers</linktext> </link> <link href="GUID-F43A54C0-E82B-5790-8493-1372D214C642.dita"><linktext>Planes</linktext> </link> <link href="GUID-E3E4E9A1-359E-5475-A355-1DA446FE7170.dita"><linktext>Nodes</linktext> </link> </related-links></concept>
\ No newline at end of file
+<?xml version="1.0" encoding="utf-8"?>
+<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
+<!-- This component and the accompanying materials are made available under the terms of the License 
+"Eclipse Public License v1.0" which accompanies this distribution, 
+and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
+<!-- Initial Contributors:
+    Nokia Corporation - initial contribution.
+Contributors: 
+-->
+<!DOCTYPE concept
+  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
+<concept xml:lang="en" id="GUID-F8069628-BD32-535C-963A-A1CF8172E275"><title>What are CF Protocols, Binders, and Flows</title><shortdesc>This topic describes the concepts of <i>Communications Framework (CF) Protocols</i>,<i>Binders</i> and <i>Flows</i> in the Communications Framework. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody><p>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 <b>Communications Framework Protocol</b> (CF Protocol). </p> <fig id="GUID-293BE7D5-9C9D-5A17-9C61-5FA19B06490C"><title>
+          Figure 1 - A CF Protocol in the Layered Comms Stack 
+        </title> <image href="GUID-9FB82D95-F110-5D42-B39E-BCFAE574E18F_d0e77328_href.png" placement="inline"/></fig> <p>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. </p> <section><title>CF Protocol components</title> <fig id="GUID-171654F9-312C-547C-A886-E16A9DB21040"><title>
+             Components of a CF Protocol 
+          </title> <image href="GUID-E63899B3-8EA8-5EF7-982E-EC161B3A4794_d0e77341_href.png" placement="inline"/></fig> <p>A CF Protocol is constructed of two main components: </p> <ul><li id="GUID-B9E64AE4-CC30-5085-82D1-938C397A4FD3"><p> <b>Flow</b> - 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. </p> </li> <li id="GUID-6A394EF2-EFD4-5885-BE40-A62784A85E2B"><p> <b>Binder</b> - 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. </p> <p>A <b>Protocol Binder</b> 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. </p> <p>A <b>Session Binder</b> 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. </p> </li> </ul> </section> <section id="GUID-832AD765-692C-56BE-92AC-AF8AEFB69413"><title>Flow</title> <p>A Flow is an instance of a class which represents a single conversation with a remote peer. </p> <p>There may be many active Flows in a CF Protocol to represent many concurrent conversations through the same instance of the CF Protocol. </p> <p>A Flow is a Stack Node created and controlled by one SCPR. </p> <p>Configuration data for the Flow is provisioned directly by the SCPR and usually originates from the MCPR. </p> <p>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. </p> <p>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. </p> <p>Each Flow must serve the following messages: </p> <ul><li id="GUID-CF546C5F-B597-528B-8A7D-3D9AB804291F"><p> <xref href="GUID-413B79AB-EFA4-3C29-842B-F4DFE2C5A87D.dita"><apiname>TBindTo</apiname></xref> - tells the Flow which lower Flow to bind to </p> </li> <li id="GUID-31FDA6FA-251D-5E98-A194-E134EF953311"><p> <xref href="GUID-F2EEF015-3165-32D6-B98C-E77B2BDFDCDF.dita"><apiname>TProvisionConfig</apiname></xref> - carries a configuration object </p> </li> <li id="GUID-B4D38D5B-5537-5882-A7D0-F5A1AEC9E34C"><p> <xref href="GUID-2257D314-72A9-3A2A-9E79-4BCED7AC1045.dita"><apiname>TStartFlow</apiname></xref> - starts the Flow </p> </li> <li id="GUID-3DB58B6B-32E0-5B0A-B8D1-3D6B6CDF41A0"><p> <xref href="GUID-74EDDB44-5E1B-34CF-9678-C7C8811C7D58.dita"><apiname>TStopFlow</apiname></xref> - stops the Flow </p> </li> <li id="GUID-1BAC8A9D-94D6-5E96-BEAE-0EC97537EA16"><p> <xref href="GUID-9E005556-76E5-306B-982C-B2C2BC268EB8.dita"><apiname>TDestroy</apiname></xref> - instructs the Flow to delete itself </p> </li> <li id="GUID-DF01A012-4D45-5670-A62A-91ADA3303A10"><p> <xref href="GUID-B61247EA-48AE-301B-8089-0B5E67B5E04C.dita"><apiname>TStateChange</apiname></xref> - the Flow should send this whenever it wants to inform the control side of its state change </p> </li> </ul> </section> <section id="GUID-B09A95DB-93A8-5D36-BB95-40DA8766E3A0"><title>Binder</title> <p>The Binder is split into two parts: </p> <ul><li id="GUID-261D54B9-E404-5282-A322-A98EC5693DCF"><p> <i>Binder Control</i> - used by the upper layer to set up the binding with the lower layer. </p> </li> <li id="GUID-5D596068-F8A6-564C-A084-82FAB47B2035"><p> <i>Binder</i> - 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. </p> </li> </ul> <p>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. </p> <p id="GUID-C16F3524-AFFE-5E0B-82A7-8EC9B12BA660"><b>Protocol Binder</b> </p> <p>A Protocol Binder is used by the Flow as the link to the next higher CF Protocol for inbound data. </p> <p>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. </p> <p>Protocol Binders are most commonly used for lower-level protocols (nearer the hardware) rather than the higher-level Link layer protocols. </p> <p id="GUID-E6B2C4D3-BE14-53DC-8616-5D3BC2B14686"><b>Session Binder</b> </p> <p> 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. </p> </section> </conbody><related-links><link href="GUID-01029B52-55E0-5598-994F-BB5DE73D37EE.dita"><linktext>Layers</linktext> </link> <link href="GUID-F43A54C0-E82B-5790-8493-1372D214C642.dita"><linktext>Planes</linktext> </link> <link href="GUID-E3E4E9A1-359E-5475-A355-1DA446FE7170.dita"><linktext>Nodes</linktext> </link> </related-links></concept>
\ No newline at end of file