Smartphone Operating System (779883), страница 51
Текст из файла (страница 51)
The abstractness ofthe model can be seen in how it is used: each side simply writes data to andreads data from a socket as if it were a local I/O device. Each side reallydoes not know (or care) how the other side reads or processes the data.In fact, the socket may implement translation of data, again without eachside knowing (or caring). The translation is implemented by the operatingsystem and occurs as the data is transferred between the endpoints.236MODELING COMMUNICATIONSEvent-driven CommunicationsWaiting is something built into the use of communications. Whethercommunications is with a device, another process, or another computer,the act of exchanging communications data means that some waiting mustoccur on the other side’s response. As we discussed in Chapter 9, waitingfor device I/O is dealt with by means of interrupts.
Asynchronous eventsserve as software interrupts for communications to other computers.The idea behind communications events is the same as with device I/O.We use the idea of an ‘event’ to represent the occurrence of somethingthat an application might be waiting for in a communications exchange.There are many events that are specified to represent communications.A process registers an interest in certain communications events andthe operating system takes care of receiving the communications andnotifying the process when communications data is ready. This meansthat, like with device I/O, the process involved can do other tasksconcurrently with the waiting for communications.This asynchronous event model is useful in several ways.
It keepsapplications from freezing while they wait for an event. It allows the system to interleave instructions more efficiently from concurrent processesor threads. It also allows the system to put the entire device to sleep incertain cases (e.g., when all processes are waiting for events) to conservebattery power.The Symbian OS concept of active objects is an excellent example ofcommunications events.
As we have discussed in previous chapters, anactive object is a specialized object that allows requests to be made thatwould otherwise force waiting, going to sleep to avoid a polling loop andhandling the event that is generated when the request gets a response bywaking up and continuing execution. By building into Symbian OS theconcept of an active object as a thread, the designers of Symbian OS builtan object that can handle waiting for responses from communicationsand not prevent other code from running.Consider an email application as an example of an active object.Email can be collected by sending a request to a server. A response israrely immediate, especially if there are many messages to pick up.
Ifan application were not to use active objects, the application would belikely to freeze up while waiting for all the messages to download. Thissituation would occur because the application would be concentratingon the data exchange with the email server and not on listening for stylustaps or updating the screen. However, if the application used an activeobject to communicate with the server, then it could respond to the userCOMMUNICATIONS ON SYMBIAN OS237at the same time it was waiting for messages.
Active objects enable moreinteraction with applications and a clean interface for handling situationsthat might arise during communications.For many operating systems, it is possible not to use an event-drivenmethod for communications. Waiting for communications data is alsoavailable for processes. If a process has no other tasks to attend to or has aneed to react immediately when communications data arrives, then it canmake the standard system calls that block until data arrives on a socket.11.2Communications on Symbian OSSymbian OS provides a great example of our general communicationsmodel discussion. It was designed with specific criteria in mind and canbe characterized by event-driven communications using client–serverrelationships and stack-based configurations.Basic InfrastructureA good way to start looking at the Symbian OS communications infrastructure is by examining its basic components.
Let’s start by consideringthe generic form of this infrastructure shown in Figure 11.5.ApplicationProtocol implementationSOFTWAREDevice driverPhysical deviceHARDWAREFigure 11.5 Basic depiction of Symbian OS communications infrastructure238MODELING COMMUNICATIONSConsider Figure 11.5 as a starting point for an organizational model.At the bottom of the stack is a physical device, connected in some wayto the computer. This device could be a mobile phone modem or aBluetooth radio-transmitter embedded in a communicator.
Since we arenot concerned with the details of hardware here, we treat this physicaldevice as an abstract unit that responds to commands from software inthe appropriate manner.The next level up – the first level we are concerned with – is thedevice-driver level. The software at this level is concerned with workingdirectly with the hardware via a fixed, standardized interface to the uppersoftware layers. The software at this level is hardware-specific and everynew piece of hardware requires a new software device driver to interfacewith it. Symbian OS comes with a set of device drivers for commonlyused pieces of hardware (e.g., wireless Ethernet clients or Bluetoothtransmitters). Different drivers are needed for different hardware units,but they must all implement the same interface to the upper layers.
Theprotocol implementation layer expects the same interface no matter whathardware unit is used.Standards play a major role with Symbian OS device drivers. Hardware is becoming increasingly standardized and sometimes one devicedriver can manage several pieces of hardware because they all abideby the same standard. For example, many serial devices – modemsor IR ports – can be controlled by a single device driver. In addition, protocol implementations are increasingly assuming device-driverstandards. Standards such as Bluetooth or wireless Ethernet, for instance,are becoming widely supported and therefore must be incorporated inthe device-driver layer.The next layer up is the protocol-implementation layer.
This layercontains implementations of the protocols supported by Symbian OS.These implementations assume a device-driver interface with the layerbeneath and supply a single, unified interface to the application layerabove. This is the layer that implements the Bluetooth and TCP/IP protocolsuites, for example, along with other protocols.Finally, the application layer contains the application that must utilizethe communications infrastructure. The application does not know muchabout how communications are implemented – however, it does do thework necessary to inform the operating system of which devices it use.Once the drivers are in place, the application does not access themdirectly, but depends on the protocol-implementation-layer APIs to drivethe real devices.COMMUNICATIONS ON SYMBIAN OS239A Closer Look at the InfrastructureNow let’s take a closer look at the layers in Symbian OS communicationsinfrastructure.
Figure 11.6 contains a new diagram based on the genericmodel in Figure 11.5. The blocks from Figure 11.5 have been subdividedinto operational units that depict those used by Symbian OS.The physical deviceFirst, notice that the device has not been changed. As we stated before,Symbian OS has no control over hardware. Therefore, it accommodateshardware through this layered API design, but does not specify howthe hardware itself is designed and constructed.
This is an advantageto Symbian OS and its developers. By viewing hardware as an abstractunit and designing communications around this abstraction, the designersApplicationUser-side codeCSY communication module (application)Protocol ImplementationMTM modulePRT protocol moduleTSY communication moduleCSY communication moduleSOFTWAREDevice DriverLogical device driverPhysical device driverPhysical deviceHARDWAREFigure 11.6 Detailed look at the Symbian OS communications infrastructure240MODELING COMMUNICATIONShave ensured that Symbian OS handles the wide variety of devices thatare available now and that it can accommodate the hardware of thefuture.The device-driver layerThe device-driver layer of Figure 11.5 has been divided into two layersin Figure 11.6.
The physical device-driver (PDD) layer interfaces directlywith the physical device, through a specific hardware port. The logicaldevice-driver (LDD) layer interfaces with the protocol-implementationlayer and implements Symbian OS policies as they relate to the device.These policies include input and output buffering, interrupt mechanismsand flow control. The division of these layers represents a division inimplementation, where the PDD implementers can focus on an efficientand correct hardware interface and the LDD implementers can work toperfect the interface with the upper layers to maximize performance.User code interfaces with the LDD through the RBusLogicalChannel class.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
