Symbian3/PDK/Source/GUID-12C9C36B-8AD4-544E-A6A3-54A799EF0280.dita
author Dominic Pinkman <Dominic.Pinkman@Nokia.com>
Thu, 11 Mar 2010 18:02:22 +0000
changeset 3 46218c8b8afa
parent 1 25a17d01db0c
child 5 f345bda72bc4
permissions -rw-r--r--
week 10 bug fix submission (SF PDK version): Bug 1892, Bug 1897, Bug 1319. Also 3 or 4 documents were found to contain code blocks with SFL, which has been fixed. Partial fix for broken links, links to Forum Nokia, and the 'Symbian platform' terminology issues.

<?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 reference
  PUBLIC "-//OASIS//DTD DITA Reference//EN" "reference.dtd">
<reference xml:lang="en" id="GUID-12C9C36B-8AD4-544E-A6A3-54A799EF0280"><title>Socket Server Reference</title><shortdesc>This topic provides a summary of related documentation for the ESock APIs. </shortdesc><prolog><metadata><keywords/></metadata></prolog><refbody><section><p>Socket Server APIs: </p> </section> <table id="GUID-C269B63A-A1D7-5A4B-8608-65462143CBA6"><tgroup cols="4"><colspec colname="col0"/><colspec colname="col1"/><colspec colname="col2"/><colspec colname="col3"/><thead><row><entry>Server session APIs</entry> <entry/><entry>Header</entry> <entry>Description</entry> </row> </thead> <tbody><row><entry><p> <xref href="GUID-EF29C1D7-B1E5-370F-AE37-66231A6BE449.dita"><apiname>RSocketServ</apiname></xref>  </p> <p> </p> <p> </p> <p> </p> <p> </p> <p> </p> <p> </p> <p> </p> </entry> <entry><p> </p> </entry> <entry><p>ES_SOCK.H </p> </entry> <entry><p>RSocketServ establishes and reserves resources for the base communication session to the socket server. All other client interfaces require a valid session to be opened </p> </entry> </row> <row><entry><p> <b>RSocketServ Subsession APIs</b>  </p> </entry> </row> <row><entry><p> <xref href="GUID-D4F08503-F1EF-3531-9C3C-4AF24A6255F0.dita"><apiname>RSocket</apiname></xref>  </p> </entry> <entry><p>ES_SOCK.H </p> </entry> <entry><p>End point for all socket-based communications. </p> </entry> </row> <row><entry><p> <xref href="GUID-B16CAD6D-85B1-3482-AAC0-9BADEDB6ABDD.dita"><apiname>RHostResolver</apiname></xref>  </p> </entry> <entry><p>ES_SOCK.H </p> </entry> <entry><p>Makes host name resolution queries. </p> </entry> </row> <row><entry><p> <xref href="GUID-BED8A733-2ED7-31AD-A911-C1F4707C67FD.dita"><apiname>RConnection</apiname></xref>  </p> </entry> <entry><p>ES_SOCK.H </p> </entry> <entry><p>Used to startup and manage active connections. It is possible to start a connection either implicitly, via the RSocket or RHostResolver APIs, or explicitly via the RConnection API. The RConnection creates a default subconnection. </p> <p> <xref href="GUID-5CFC075C-8F53-5E1B-A111-C6F4567DFD1E.dita">RConnection API Reference</xref>  </p> </entry> </row> <row><entry><p> <xref href="GUID-0AFDA357-EE44-3788-9CAB-162B874134BF.dita"><apiname>RSubConnection</apiname></xref>  </p> </entry> <entry><p>ES_SOCK.H </p> </entry> <entry><p>Used to organise channels within a connection and manage Quality of Service. Multihoming-aware applications must use this API. Only valid in the context of an RConnection. </p> </entry> </row> <row><entry><p> <xref href="GUID-7489739B-3608-3F9F-BB02-DE65D7AA53A2.dita"><apiname>RNetDatabase</apiname></xref>  </p> </entry> <entry><p>ES_SOCK.H </p> </entry> <entry><p>Interface for network database access. </p> </entry> </row> <row><entry><p> <xref href="GUID-DDD32F28-BA89-3CA1-93B0-355CDD9CD92D.dita"><apiname>RServiceResolver</apiname></xref>  </p> </entry> <entry><p>ES_SOCK.H </p> </entry> <entry><p>Provides an interface to resolve service names and ports. </p> </entry> </row> <row><entry><p> <xref href="GUID-55FE59B7-4FA9-3B1A-BD4C-9B7611FE75C2.dita"><apiname>RConnectionServ</apiname></xref>  </p> </entry> <entry/><entry><p>ES_SOCK.H </p> </entry> <entry><p>Provides access to the Comms Management Plane, including Access Point queries. </p> </entry> </row> </tbody> </tgroup> </table> <section><p>Bearer Mobility APIs </p> </section> <table id="GUID-DDBADF88-8197-5C9A-AC0E-42099252DC93"><tgroup cols="3"><colspec colname="col0"/><colspec colname="col1"/><colspec colname="col2"/><thead><row><entry>Bearer mobility APIs</entry> <entry>Header</entry> <entry>Description</entry> </row> </thead> <tbody><row><entry><p> <xref href="GUID-6CA83252-4D0C-3B72-83ED-B5152B666C83.dita"><apiname>CActiveCommsMobilityApiExt</apiname></xref>  </p> </entry> <entry><p>es_mobility_apiext.h </p> </entry> <entry><p>Comms Mobility API extension for application client running an Active Scheduler. </p> </entry> </row> <row><entry><p> <xref href="GUID-D5F43DFB-5143-3563-8655-16E245A9735F.dita"><apiname>RCommsMobilityApiExt</apiname></xref>  </p> </entry> <entry><p>es_mobility_apiext.h </p> </entry> <entry><p>Comms Mobility API extension for application client not running an Active Scheduler. </p> </entry> </row> <row><entry><p> <xref href="GUID-9A3979A9-F882-3053-B5B1-E0E125774271.dita"><apiname>MMobilityProtocolResp</apiname></xref>  </p> </entry> <entry><p>es_mobility_apiext.h </p> </entry> <entry><p>Interface to be implemented by the application client to support mobility API extension. See <xref href="GUID-CB1E1921-9CF7-55B7-9F70-6AD61A961208.dita">Bearer Mobility Client</xref>. </p> </entry> </row> </tbody> </tgroup> </table> <section><p>How APIs related to the 3-Plane Comms Architecture. </p> <fig id="GUID-FC69453E-CA12-5CDB-A7E6-B2FA542BBE06"><title>
          Figure 1 - How ESock APIs related to the 3-Plane Comms Architecture 
        </title> <image href="GUID-239B8B32-5816-575E-97B1-FF7B68BC7575_d0e124419_href.png" placement="inline"/></fig> <p>The Sockets Client API also defines a number of support classes used in conjunction with the above interfaces. These encapsulate: </p> <ul><li id="GUID-A1132B04-61D5-53E5-85A5-E7BBFA598B72"><p> <i>Addresses</i>: a base address class <xref href="GUID-66228064-B6E7-3CE9-8F5E-5DED4CD9A49B.dita"><apiname>TSockAddr</apiname></xref> is defined. Specific protocol address classes are derived from this. Each address can be identified by its Protocol Family, an integer which identifies protocol suites from others. </p> </li> <li id="GUID-BBD21B5C-20EE-5BC9-BEE4-00CB1565DE1E"><p> <i>Resolution queries</i>: queries made through <xref href="GUID-B16CAD6D-85B1-3482-AAC0-9BADEDB6ABDD.dita"><apiname>RHostResolver</apiname></xref> objects are packaged in <xref href="GUID-C625E339-6726-3FB9-8F8A-F4DB0CAC15FF.dita"><apiname>TNameEntry</apiname></xref> descriptors. These are packages for <xref href="GUID-567CF5B5-464F-37B7-A91E-6A672C39BA44.dita"><apiname>TNameRecord</apiname></xref> objects that contain <xref href="GUID-66228064-B6E7-3CE9-8F5E-5DED4CD9A49B.dita"><apiname>TSockAddr</apiname></xref> objects to pass in addresses. </p> </li> <li id="GUID-EFB76FB6-00D2-5C01-BE59-B748CAAAC61E"><p> <i>Protocol information</i>: a comprehensive description of a protocol’s capabilities and properties can be dynamically obtained through the <xref href="GUID-0FB20F20-67EE-3948-B9F6-E1D679AC3D0F.dita"><apiname>TProtocolDesc</apiname></xref> class. Capabilities are identified by constants. </p> </li> <li id="GUID-4BD6B3AA-4711-55BE-8F34-88B28EC2657F"><p> <i>Endian issues</i>: <xref href="GUID-8183BE9B-6118-3472-A271-8409751CA5EF.dita"><apiname>BigEndian</apiname></xref>, <xref href="GUID-55FDB45E-2759-3192-AEE2-D600B232682B.dita"><apiname>LittleEndian</apiname></xref>, and <xref href="GUID-A934C24D-0E90-3D33-B4FC-654FB9004CFC.dita"><apiname>ByteOrder</apiname></xref> can be used to order integers to and from network order. </p> </li> </ul> </section> <section id="GUID-7803B89A-6ABF-529C-A0B8-CA06BA410F3B"><title>RSubConnection Events</title> <p> <b>CSubConGenEventDataClientJoined</b>, <b>CSubConGenEventDataClientLeft</b>  </p> <p>These two events derive from <xref href="GUID-1C0CC85E-38A7-3E7A-9246-940DCCE44EB0.dita"><apiname>CSubConGenEventDataClientBase</apiname></xref>, which provides the functionality for both. The source and destination end points of the data client are presented with this event, along with the IAP ID of the connection on which it was created. </p> <p> <b>CSubConNotificationEvent</b>  </p> <p>Both generic and extension sub-connection events derive from this class. The rules for generic and extension events are the same as for parameter sets. That is, a generic event MUST be able to be understood by all technologies. </p> <p>The <codeph>IsGeneric()</codeph> method identifies whether the event is generic. </p> <p>The <codeph>GroupId()</codeph> method returns the UID of the factory that contains the event, and <codeph>Id()</codeph> returns the class type Id within that factory. These two pieces of information comprise the <xref href="GUID-FEE87408-3FAA-31BB-A0C2-4BDEB279D4BA.dita"><apiname>STypeId</apiname></xref> of the event. </p> <p> <b>CSubConGenEventParamsGranted</b>  </p> <p>Notification of this event occurs after a request to <codeph>SetParameters()</codeph> has been made and negotiation with the network has been completed. A notification will be received for each family contained in the parameter bundle that was negotiated successfully. This event presents a generic set and zero or more extension sets (providing they are supported by the underlying sub-connection provider technology) of the parameter family identified by the Id returned from <codeph>GetFamily()</codeph>. </p> <p> <b>CSubConGenEventParamsRejected</b>  </p> <p>Notification of this event occurs after a request to <codeph>SetParameters()</codeph> has been made and negotiation with the network has failed for some reason. It could be an error within the handset software/configuration, or that the network could not provide the acceptable (minimum) level of QoS. The reason for failure and the parameter family are presented by the accessor methods <codeph>Error()</codeph> and <codeph>FamilyId()</codeph>. Like the <xref href="GUID-AA6CFA1E-0B17-3603-9065-34D05322C0A5.dita"><apiname>CSubConGenEventParamsGranted</apiname></xref> event, a notification for <xref href="GUID-7103CFA3-2119-3356-9460-B26D88036FEB.dita"><apiname>CSubConGenEventParamsRejected</apiname></xref> is received for each family in the parameter bundle that could not be negotiated successfully. </p> <p> <b>CSubConGenEventParamsChanged</b>  </p> <p>This event occurs when the properties of a parameter family has been renegotiated due to some event on the network. It is not sent in response to a request to change the properties. The change could be the result of an error or just that the level of QoS has improved/worsened. If a new set of parameters are available they’ll be presented as with the <xref href="GUID-AA6CFA1E-0B17-3603-9065-34D05322C0A5.dita"><apiname>CSubConGenEventParamsGranted</apiname></xref> event. The error status is presented via the <codeph>Error()</codeph> method. </p> <p> <b>CSubConGenEventSubConDown</b>  </p> <p>This event occurs when the underlying sub-connection has been lost. This could be due to request for it to be closed, or some error on the network. The error status is presented via the <codeph>Error()</codeph> method. </p> </section> <section id="GUID-7F057E16-0E56-5989-8647-7DAFF6E343D3"><title>RSubConnection QoS Parameters</title> <p> <b>CSubConQosGenericParamSet</b>  </p> <table id="GUID-227CFC6C-C38B-516F-AB6D-C3C2D51EA4A3"><tgroup cols="3"><colspec colname="col0"/><colspec colname="col1"/><colspec colname="col2"/><thead><row><entry> Parameter </entry> <entry> Description </entry> <entry>Directions</entry> </row> </thead> <tbody><row><entry><p>Bandwidth </p> </entry> <entry><p>Bandwidth the client requires </p> </entry> <entry><p>Uplink / Downlink </p> </entry> </row> <row><entry><p>Maximum Burst Size </p> </entry> <entry><p>Maximum size of a burst of data the client can handle </p> </entry> <entry><p>Uplink / Downlink </p> </entry> </row> <row><entry><p>Average Packet Size </p> </entry> <entry><p>Average packet size required (e.g. codec use) </p> </entry> <entry><p>Uplink / Downlink </p> </entry> </row> <row><entry><p>Maximum Packet Size </p> </entry> <entry><p>Maximum packet size the client can handle </p> </entry> <entry><p>Uplink / Downlink </p> </entry> </row> <row><entry><p>Delay </p> </entry> <entry><p>Acceptable Delay/Latency </p> </entry> <entry><p>Uplink / Downlink </p> </entry> </row> <row><entry><p>Delay Variation </p> </entry> <entry><p>Acceptable variation in delay (also known as jitter) </p> </entry> <entry><p>Uplink / Downlink </p> </entry> </row> <row><entry><p>Priority </p> </entry> <entry><p>Relative priority the client expects to give this channel compared to it’s other channels </p> </entry> <entry><p>Uplink / Downlink </p> </entry> </row> <row><entry><p>Header mode </p> </entry> <entry><p>Specify whether the header size should be calculated by the QoS module or specified by the client. Default is to let the QoS module calculate it. </p> </entry> <entry><p>N/A </p> </entry> </row> <row><entry><p>Name </p> </entry> <entry><p>Identity of a “well known” set of QoS Parameters. </p> </entry> <entry><p>N/A </p> </entry> </row> </tbody> </tgroup> </table> <p>If an extension parameter set is added to the family that contains conceptually identical parameters to those in the generic set, it is recommended that you set both instances (generic and extension) of those parameters. </p> <p> <b>CSubConQosIPLinkR99ParamSet</b> / <b>CSubConQosR99ParamSet</b>  </p> <p>Getter and setter methods are provided for each parameter. </p> <p> <b>Note: </b> The constants used for it are <xref href="GUID-04E17A74-BFAB-3DB7-998B-5BCB8A5FB4CC.dita"><apiname>KSubConIPParamsUid</apiname></xref> and <xref href="GUID-41202CC9-3547-3404-AF6C-678A36BAE7D9.dita"><apiname>KSubConQosIPLinkR99ParamsType</apiname></xref>. </p> <p>The following parameter sets are available in Symbian OS v9.3 onwards. </p> <p> <b>CSubConQosR5ParamSet</b>  </p> <p>It inherits from the release 4/99 set <codeph>CSubConQosR99ParamSet</codeph>. Although it is possible to add both this parameter set and the R4/R99 one, it is not necessary and should not be done. </p> <p> <b>CSubConIMSExtParamSet</b>  </p> <p>This class contains the IM CN Signalling Indicator flag. </p> </section> <section><title>Test programs</title> <p>None </p> </section> <section><title>Historial Node</title> <p> <b>Note: </b> In Symbian OS v9.2, the <xref href="GUID-BE599F52-46BD-3BB4-8B18-E149633AD0E5.dita"><apiname>CSubConQosR99ParamSet</apiname></xref> class replaced the <xref href="GUID-D378B4C3-C1DD-3B79-9608-6BC53835E1A3.dita"><apiname>CSubConQosIPLinkR99ParamSet</apiname></xref> class. </p> </section> </refbody></reference>