Symbian OS Communications (779884), страница 6
Текст из файла (страница 6)
Despite this(internal) delegation, the interface to the DNS service is provided throughthe standard ESOCK APIs.The IP stack has the ability to load plug-ins that can intercept andmodify packets as they pass through the stack; however these interfacesare partner-only, and so are not described in this book.Access to particular network technologies is performed using a combination of a network interface (NIF) and an agent (AGT).
The normalseparation of responsibility is that the network interface is a lightweightpacket processor that sits on the data path, whereas the agent contains thelogic to make and manage the connection. With certain network protocols though, the line is blurred, and therefore certain NIFs contain code toperform configuration of the interface – the Point-to-Point Protocol (PPP)NIF being a prime example.On the control side, there is also the network interface manager(NIFMAN) and the network controller (NETCON), which, together withESOCK, provide the framework for creating and managing IP connections.HIGH-LEVEL FUNCTIONALITY19NIFMAN also provides a system for plugging in network configuration mechanisms independently of underlying network technologies – atpresent the DHCP client implementation is the only example of sucha plug-in.SMSThe short message service (SMS) stack is also a plug-in to the ESOCKframework.
It provides various lower level services involved in sendingan SMS, including fragmenting messages that are too long to fit in a singleprotocol data unit (PDU). It also provides APIs to allow applicationsto receive SMS messages before they are delivered to the messagingstore – a useful feature for pushing information to your application withouttriggering an irrelevant indication to the user. These APIs are coveredfurther in Chapter 8.2.1.3 ETelETel provides the lowest level interface to the telephony functionalitywithin Symbian OS. Below ETel is the realm of the device-specificadaptation, which converts ETel API calls into whatever form is necessaryfor the specific baseband stack that is in use – this is the job of the TSY(Telephony SYstem module).Because ETel provides a very low-level API, Symbian implement awrapper over this called ‘ETel 3rd party’, which provides a limited subsetof the functionality available in the ETel API in an easy-to-use form.
Adiscussion of this API and the functionality available is in Chapter 7.2.1.4 Serial ServerThe serial server provides, perhaps unsurprisingly, the interface to serialports, both real and virtual. A series of plug-ins, called Comms SYstemplug-ins (CSYs, see Figure 2.4), provide access to specific technologies – RS-232 physical serial ports (rarely found on phones today), andBluetooth, infrared and USB virtual serial ports. Some products containadditional, product-specific CSYs for communicating with other parts ofthe system, such as the cellular modem, but these are rarely useful todevelopers.
Since USB is not covered in this book, and RS-232 ports areso rarely encountered, virtual serial ports over Bluetooth and infrared arecovered in the respective technology chapters.2.2 High-level FunctionalityNow it’s time to look at the functionality built on top of the low-levelservices that we’ve just discussed.20OVERVIEWSerial serverBTCOMMCSYIPCOMMCSYFigure 2.4Other CSYsSerial server and CSYs2.2.1 MessagingMessaging functionality in Symbian OS is based around the messagingserver, and a series of plug-ins called Message Type Modules (MTMs), asshown in Figure 2.5.
By default, Symbian OS-based phones ship with arich set of MTMs built-in, including ones for SMS, MMS, IMAP4, POP3,SMTP and OBEX over Bluetooth and IrDA (for transferring objects betweendevices at short range). This set can be extended – there are MTMs available from many push email providers, as well as from other third parties.A set of plug-ins to support a single messaging technology consistsof four different MTMs – a server MTM, a client MTM, a UI MTM anda UI data MTM. Together they form a complete solution for adding anew message transport to the messaging architecture; although compleximplementations may choose to provide some of the functionality of theUI MTM in separate applications.
The purpose and responsibilities ofeach type of MTM are described in the second part of Chapter 9.On top of messaging is built the SendAs service, which allows applications to send data to remote devices using an abstract API – this allowsthe set of technologies that can be used to send messages to be extended,UI MTMClientapplicationUI data MTMClient MTMMessaging serverMessage storeServer MTMFigure 2.5Message server and MTMsHIGH-LEVEL FUNCTIONALITY21based on MTMs available on the system that support the SendAs service,without the application using the service having to change.Chapter 8 covers receiving messages, and contains details of usingvarious messaging APIs to access the message store.
Chapter 9 coverssending messages using the SendAs service, including the UI-specificwrappers around it, as well as describing how to create a new set of MTMsto enable additional message transports to be added to the SendAs service.2.2.2 OBEXOBEX was originally created by the IrDA specifications body as anefficient means of exchanging objects, and has since been extended tosupport a variety of other transport protocols, such as Bluetooth andUSB. OBEX performs a similar role to the more popular HTTP protocol.There are many similarities between the two – both are request-responseprotocols, both are designed to transfer arbitrary data between devices,and both use the concept of headers describing the content and bodiescontaining it.OBEX is designed to be easier to implement in resource-constraineddevices than HTTP. It is also designed to be more efficient in terms ofbandwidth, using a binary encoding scheme for headers rather than a textbased one.
And the OBEX protocol itself is stateful, unlike HTTP whichis fundamentally stateless and uses the additional concept of cookies tomaintain state.In Symbian OS, the OBEX stack is loaded into the client’s process.As well as the core stack, there are a number of transport plug-ins asseen in Figure 2.6 – for IrDA, Bluetooth and USB. In order to use theOBEX stack the client’s process must have the appropriate capabilitiesto perform the operations that OBEX attempts – the required capability isLocalServices for existing transports.OBEX is used to transport data in a number of use cases – mostcommonly in the use case it was originally designed to fulfil – the transferof objects such as vCards between devices.
However, it is also used ina number of other Bluetooth specifications, including advanced imagetransfer and printing, and also as a transport protocol for OMA SyncML.OBEX stackBT transportplug-inIR transportplug-inUSB transportplug-inFigure 2.6 The OBEX stack and transport plug-ins22OVERVIEWChapter 10 describes the Symbian OS implementation of OBEX, showing how to connect transport sessions, as well as build, parse andexchange objects.2.2.3 HTTPHTTP is most familiar as the protocol that serves up web pages on theInternet. Symbian OS contains an HTTP stack that is available for anyapplication to use.
The HTTP stack is loaded in the client’s process, andcan be extended with client-supplied plug-ins. As it runs in the client’sprocess the client must have the appropriate capabilities to perform theoperations that the HTTP stack attempts – currently this is the capabilityNetworkServices. Figure 2.7 shows the high level architecture of theHTTP stack.As mentioned in the OBEX section, at a high-level HTTP and OBEXfulfil similar roles – they both provide a system for transferring arbitraryobjects between a client and a server.The Symbian OS HTTP stack supports HTTP/1.0 and HTTP/1.1, andas part of HTTP/1.1 it supports persistent connections and pipelining.
Italso supports basic and digest authentication, and HTTP over TLS usingthe ‘https’ URI scheme. A number of HTTP error codes, such as thosefor redirection are handled transparently. Chunked transfer encoding issupported, however, content encodings are not, by default, implemented,although that’s not to say there isn’t a filter providing them on a given UIplatform.The HTTP stack can be extended at runtime by the use of plugins called filters.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
