Symbian OS Communications (779884), страница 5
Текст из файла (страница 5)
Detailed explanationsof how things work will be left to the individual technology chapters, buthere we’ll take a quick look at what each area does.First we have something of an aside, but on an important topic – thatof binary compatibility (BC).Symbian OS v9.0 introduced a major BC break with versions 8.1and earlier, due to the introduction of a new (standardized) applicationbinary interface (ABI). Therefore applications compiled against v8.1and earlier of Symbian OS will not run on v9.1 and later. In addition tothis, the platform security model requires some changes to applicationsusing communications functionality. Depending on the application thismight be as simple as adding a CAPABILITY statement to the MMPfile.To start with we take a quick look at a very high-level model of howa Symbian OS-based phone is constructed in order to see where variouscomponents fit in.
This isn’t to say every phone looks like this, but it isa good enough model to help understand the different layers that existwithin Symbian OS.The signalling stack (also referred to as the ‘baseband’ or ‘cellularmodem’) is provided by the manufacturer of the device, so Symbian OScontains a series of adaptation layers to allow standard Symbian OS APIsto be adapted to the specific signalling stack in use. Today, all shippingproducts use either a 2.5G GSM/GPRS or 3G UMTS (aka W-CDMA,aka 3GSM) signalling stack. In Figure 2.1, you can see the layers thatform the adaptation coloured grey – we’ll talk a little about each of thesethroughout this chapter.14OVERVIEWHTTP clientPhoneapplicationMessagingserverBT clientIP clientHTTP stackESockETelSerial serverTSYIP stackNIFBluetoothstackIRCOMM CSYSMS stackTo BThardwareBTCOMM CSYIrDA stackTo infraredhardwareCellular basebandFigure 2.1High-level overview of Symbian OS communications architecture2.1 Low-level FunctionalityWe’ll split our overview into two main sections, following those that thewhole book uses, in order to partition the system more clearly.
In this firstpart of the chapter we’ll talk about the technologies in section 2 – thelower level areas such as the Bluetooth, IrDA and IP stacks, along withtelephony. In the second part we’ll discuss more about messaging, OBEX,HTTP and OMA Device Management.There are a couple of key frameworks involved in Symbian OS communications, so let’s look at those first.
Not everything fits into theseframeworks (most of the higher level functionality in section 3 does not,for example) but they provide the foundation for the topics discussed insection 2.Symbian OS undergoes continual development, so details on theinternals are subject to change. Public interfaces (publishedAll inSymbian parlance), which make up most of the content of this book,are subject to strict compatibility controls; however, internals are likelyto evolve over time. When we’re discussing internal details, which weare going to do in this chapter, we’ll make it clear so you know thatthe information may change.LOW-LEVEL FUNCTIONALITY152.1.1 The Root Server and Comms Provider ModulesRoot server and comms provider modules are internal to SymbianOS1 – therefore this whole section should be considered informational.Many of the lower level communication technologies in Symbian OSrun inside the c32exe (often abbreviated to ‘c32’) process. In the initialversions of Symbian OS (or EPOC32, as it was back then) the serialserver2 was the initial thread in this process, and provided functionalityto start further threads within the c32 process.
Today, the root serverperforms this function, loading and binding comms provider modules(CPMs) into the c32 process. The serial server, ESOCK server and ETelserver are all now loaded as CPMs by the root server. All this is doneunder the control of the c32start process, which is responsible for loadingand configuring the CPMs based on the contents of various CMI filesfound within c32start’s private directory.The exact mechanisms used to load ESOCK, ETel and the serial serveraren’t normally of any interest to us. However, as we’ll see in Chapter 13,there are some circumstances when using the emulator when we mightwant to alter which CPMs get loaded, so it’s useful to keep the aboveinformation in mind when setting up development environments forcommunications programming.2.1.2 ESOCKESOCK provides both the framework for, and the interface to, variouslower level protocols in Symbian OS.
For example, core parts of theBluetooth stack, most of IrDA, most of the TCP/IP stack, and much of theSMS stack3 exist within the ESOCK framework, and are accessed throughESOCK APIs. Figure 2.2 gives an overview of the ESOCK framework.Chapter 3 contains a lot of useful information about the public ESOCKAPIs, with additional information in the technical chapters that refer totechnologies implemented as ESOCK plug-ins, such as Bluetooth.
As youcan guess from the name, one of the key public interfaces that ESOCKprovides is based upon a sockets API.Here we’ll talk a little about what happens behind the scenes withESOCK and the various plug-ins.1Actually, the APIs are available to Symbian partners, but for the purposes of this book,that’s the same as internal to Symbian.2‘Serial server’ is also quite a recent term – originally it was called the c32 server – areflection of the fact that the hardware available for communications in the original PsionSeries 5 consisted of a serial port and an IrDA port, and therefore the serial server was theinterface to the core communications functionality in the device.3Although there are a variety of places in the system where you might choose to accessSMS messages – see Chapter 8 for details.16OVERVIEWAgain, this is information about internals, so is subject to change.ESOCK plug-ins exist in DLLs with the suffix .prt, and are loaded intothe ESOCK threads as part of the ESOCK startup mechanism.
Specifically,ESOCK looks for ESK files in the ESOCK subfolder of the c32 privatedirectory. These contain details of how to bind various protocol layerstogether, along with some protocol-specific configuration information. Aswith CMI files, we’ll see some more details of this in Chapter 13 when itcomes to setting up development environments.BluetoothThe Bluetooth standards include a rich and varied set of functionality,ranging from using wireless audio headsets for making telephone calls,through emulating an Ethernet network, to connecting keyboards to ahost.
Much of the functionality available is described in Bluetooth profiles – documents describing an end-to-end use case for a user, such asusing an audio headset with a mobile phone as a hands-free kit. Those usecases tend to be implemented completely by the time a phone reaches themarket. However, there are also APIs available to application programmers to implement their own Bluetooth-based applications and protocols.Chapter 4 describes two main areas – what is required to extend aprofile that Symbian implements (for example, interfacing to the remotecontrol functionality of the Audio/Visual Remote Control Profile (AVRCP)profile to allow your application to receive commands from a Bluetoothstereo headset) and what is required to implement Bluetooth communications between devices running your application, using one of twopossible protocols – L2CAP or RFCOMM.There are also some Bluetooth profiles which can be used withoutany Bluetooth-specific APIs.
The prime example of this is Bluetooth PANprofile, which implements a virtual Ethernet network between Bluetoothdevices. In this case, the standard APIs used for creating IP connectionsare used, although there are some special behaviors implemented to copeESockBTPRTIrDAPRTIPPRTFigure 2.2 ESOCK and protocol plug-insSMSPRTLOW-LEVEL FUNCTIONALITY17with the different models used by Bluetooth and normal, wired, Ethernetnetworks.Bluetooth functionality is implemented in several modules, which aresplit across various processes, as shown in Figure 2.3 – here we coverthe most obvious ones from a developer viewpoint. The core Bluetoothstack, implemented as an ESOCK plug-in, provides the L2CAP, RFCOMM,AVDTP and AVCTP protocols. The local service discovery database isimplemented as a standalone component, which sits above the Bluetoothstack.
The Bluetooth manager is a Symbian OS server that provides accessto the local device’s Bluetooth registry. And finally the RFCOMM CSY isthe plug-in to the serial server that allows access to RFCOMM throughthe RComm interface.One related component is the remote control server, RemCon, whichimplements a generic system for distributing commands from remotedevices, typically some form of remote control, to local applications. It’smentioned here as it is the server for the AVRCP implementation, whichreceives commands from the remote control buttons present on someBluetooth stereo headsets.
These are then routed through a UI platformspecific target selector plug-in (TSP) to the appropriate application forprocessing. There are more details on this system in Chapter 4.There are some components that we haven’t mentioned, most notablythe host controller interface (HCI) which provides the interface from theBluetooth stack to the hardware, but these are adaptation specific andtypically do not present APIs for general use.Remotecontrol serverSDP serverAVRCPplug-inSerial serverESOCKBTCOMM CSYBTPRTHCIBT hardwareFigure 2.3 High-level bluetooth architectureBTManServerBT registry18OVERVIEWIrDAIrDA is an older technology than Bluetooth, providing line-of-sightcommunications over a range of around one metre. The specificationsthemselves define fewer profile details than Bluetooth – the major profilebeing OBEX, which is covered in a separate chapter.
As such, the SymbianOS support is primarily centred on the core specifications. When usingIrDA, the two main protocols of interest are IrCOMM, for serial port emulation, and TinyTP, for stream-style communication. IrDA also providesdevice discovery and simple service discovery capabilities. Chapter 5describes the implementation of the IrDA protocols in more detail.While the IrDA committee has defined extensions to the core IrDAspecifications, Symbian OS only provides the basic services.
Key omissions are support for Fast Infrared, Fast Connect and IrSimple.IP and network interfacesSome of the details of the internals of the networking subsystem, forexample network interfaces for particular network technologies, andthe IP hooking mechanism, are internal (actually partner-only again)and therefore subject to change.Symbian OS contains a hybrid IPv4/IPv6 stack, implemented as an ESOCKplug-in. It implements all the protocols you’d expect – TCP, UDP, IPv4and IPv6, and delegates the domain name system (DNS) functionality toa separate module – the Domain Name Daemon, which performs DNSlookups and caching for all applications on the platform.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
