<?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 id="GUID-12C9C36B-8AD4-544E-A6A3-54A799EF0280" xml:lang="en"><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 id="GUID-0D8CE9A1-7056-4A0B-A3D7-8469F9029341"><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 id="GUID-2214B4F9-FC01-4B86-B9CB-3A9A3769CE9C"><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 id="GUID-3CBE467D-11B7-40F7-B681-D40F4D48D18F"><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_d0e120838_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 platform. </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 id="GUID-8797CEEF-CC6D-4B72-9C85-1B0E0188AA58"><title>Test programs</title> <p>None </p> </section>
</refbody></reference>