Symbian OS Communications (779884), страница 7
Текст из файла (страница 7)
These filters sit in the path between the client andthe TCP socket and can listen for various events and modify ongoingtransactions. The Symbian OS standard filter set includes a redirectionfilter, an authentication filter and a validation filter. UI platforms tend tointroduce additional filters, including cookie handling and caching, someof which may get added to the default set of filters that are loaded whena client loads the HTTP stack.
The HTTP stack is covered in more detailin Chapter 11.2.2.4 OMA Device ManagementWith the increasing number of services available on mobile phones, oneof the key technologies in making them easier to use is a method forremote management of configuration settings. For both network operatorsand medium and large companies, the ability to remotely provision andupdate settings on the user’s device has the potential to greatly reducethe cost of deploying new solutions.
This is the purpose of OMA DeviceManagement.Symbian OS contains a framework to which Device Managementadapters (DM adapters) can be added to manage settings for specific applications using a generic device management protocol. ThisSUMMARY23Client applicationFiltersHTTPHTTP protocol handlerSecure socketsESOCKTCP/IPFigure 2.7 The HTTP stack and filter plug-insmeans application authors, by providing a DM adapter that exposes theconfiguration settings within their application in a standard form, canenable it for remote management.The device management framework relies on the underlying SyncMLframework to provide services common to device management and datasynchronization. The common SyncML framework then provides a seriesof transport protocols over which it can be run.
DM adapters plug intothe DM framework, and provide standardized access to a variety ofunderlying settings stores – each settings store potentially being uniqueto a particular application.2.3 SummaryThat ends our overview of the different technologies described in thisbook. Hopefully you now have a high-level understanding of what eacharea does and how the different parts fit together. Next we’ll start lookingat each area in-depth. If there’s a particular area you’re interested in, feelfree to skip straight to that chapter, although it might be worth consultingthe reading guide in Chapter 1 to see if there is any suggested pre-readingfor a given chapter.Section IILow-level Technologyand Frameworks3An Introduction to ESOCKThis chapter introduces one of the core communications frameworks ofSymbian OS, ESOCK.
We will show you how to use the ESOCK APIs toconnect to a service, send and receive data, and how to allow remotehosts to connect to your own program.The example code presented in this chapter uses the ESOCK APIs,using the TCP protocol as an example – full details on how these APIs areused with a specific protocol (e.g., Bluetooth, IP or IrDA) are found in therelevant technology chapter.In this chapter we will be creating a set of wrapper classes for the rawsockets API both to demonstrate how sockets are used on Symbian OSand as a basis for your own programs.3.1 Overview of ESOCKESOCK provides two main services: the sockets API, including hostresolvers and network-based databases, for making connections withremote systems and transferring data; and the connection managementAPI for selecting, configuring and monitoring connections.3.1.1 The Sockets API OverviewThe sockets API, found in the es_sock.h header file, provides the corefunctionality for communicating over a variety of network protocols,including TCP/IP, Bluetooth and IrDA.
This includes:• name and address services to discover available communicationspartners, or to map names to network addresses• making connections to remote services28AN INTRODUCTION TO ESOCK• receiving connections from remote hosts• sending and receiving data.By providing a common idiom for accessing diverse network protocols, ESOCK makes it easier for programmers to adapt their code tonew communication technologies as they come along.
Porting still isn’tcompletely transparent, thanks to the specific details of each technology,but it’s much easier than if every protocol had a completely different APIand programming model.HistoryThe original sockets API was introduced in 4.2BSD Unix in 1983 andspread to other Unix variants before being adopted in other operatingsystems. The sockets idiom has proven enduringly popular for accessingcommunication services and is now used on the majority of operatingsystems and thus by almost all programs that need to communicate overa network.ESOCK and the sockets API were first introduced into Symbian OS inEPOC Release 1 and have been a central part of the operating systemever since. Since v7.0s, the basic socket API has been extended to copewith the unique networking environment that phones face:• the possibility of multiple access points to networks, which may havedifferent costs, availability and quality of service• certain IP-based services that can only be accessed via certain accesspoints.3.1.2 The Connection API OverviewA mobile phone today has a host of communication options.
Theseinclude short-range technologies such as infrared (IrDA) and Bluetooth,wireless LAN (WiFi), packet-switched wide-area links such as GPRS,EDGE and WCDMA, and finally circuit-switched ‘dial-up’ connections.Several of these links can be used to access an IP network, usually the Internet, but often corporate networks too, each with differentperformance (bandwidth, latency) and costs.The result is that the choice of which network access method touse is more complicated than on a PC. To allow programs to managethis complexity, the ESOCK connection API allows the enumeration,configuration and selection of the various IP connections, including theability to prompt the user to choose.Despite being originally designed for control of connections supportingIP, the connection APIs are now being extended to support the needs ofother technologies, although the set is limited as of Symbian OS v9.2.OVERVIEW OF ESOCK293.1.3 Accessing ESOCKAs ESOCK is a server running in its own thread in the C32 process, anyprogram that wants to use the ESOCK APIs must first connect to the serverto provide a client/server session.This is handled by the RSocketServ class, which provides thefollowing main methods:TInt Connect(TUint aMessageSlots=KESockDefaultMessageSlots);TInt Connect(const TSessionPref& aPref,TUint aMessageSlots=KESockDefaultMessageSlots);TVersion Version() const;TInt NumProtocols(TUint& aCount);TInt GetProtocolInfo(TUint anIndex,TProtocolDesc& aProtocol);TInt FindProtocol(const TProtocolName& aName,TProtocolDesc& aProtocol);void StartProtocol(TUint anAddrFamily,TUint aSockType,TUint aProtocol,TRequestStatus& aStatus);void StopProtocol(TUint anAddrFamily,TUint aSockType,TUint aProtocol,TRequestStatus& aStatus);The RSocketServ::Connect() methods provide the connectionto ESOCK that all other ESOCK APIs rely on.
It’s usually fine to use thedefault for the aMessageSlots parameter. If you find in testing thatyour code is getting KErrServerBusy errors then you can increase thenumber of message slots.Since Symbian OS v9.1, ESOCK uses multiple threads to run differentprotocols and because a Symbian OS client–server connection must bemade to a specific thread, by default the main ESOCK thread forwardsmessages to the right thread for the protocol in use.
If you know inadvance which protocol you’ll be using, the TSessionPref parametercan provide a speed-up by allowing a direct connection to the rightthread, saving a thread switch. This is only a hint to ESOCK, so you canstill use any protocol with this session if needed. Since thread switchingis very fast, you’re highly unlikely to notice any difference, which meansthe most usual form used for the connection is:RSocketServ ss;TInt err;err = ss.Connect(); // Default slots & protocol// check error and handleOne useful facility is the StartProtocol() call to asynchronouslyload a protocol.
Programs can use this to avoid calls toRSocket::Open() blocking while the protocol starts up, which can bea lengthy process. Typically though, most protocols that you require arealready loaded, so using this call often isn’t necessary.Despite some versions of the Symbian OS documentation claiming thisneeds the NetworkControl capability, there is no capability requiredto make this call.30AN INTRODUCTION TO ESOCKThe other RSocketServ methods allow the enumeration, finding andstopping of protocols.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
