Concepts with Symbian OS (779878), страница 49
Текст из файла (страница 49)
This is an example of a proxy server, a server that represents itsclient on another network by becoming a client itself.Communications StacksAnother way to characterize communications in an operating system isthrough a stack-based model. A stack-based approach to communicationsrecognizes that there are many different levels that analyze and usecommunications data. Each level has its own functionality and adds itsown unique properties to the communications stream.Let’s use as an example the ISO networking model. This model isshown in Figure 11.2. Each layer in the model has a specific duty andCOMMUNICATIONS MODELSApplication LayerHigh-levelProtocolsPresentation LayerSession LayerInternetworkingProtocols233Provides access for user-orientedapplications to the networkingenvironmentProvides data representationtranslation for applicationsEstablishes and manages virtual‘connections’ betweenco-operating applicationsTransport LayerProvides reliable, transparenttransfer of data betweenendpointsNetwork LayerProvides network connectionestablishment and maintenanceData Link LayerProvides reliable transfer of dataacross the physical hardwarePhysical Hardware LayerTransfers an unstructured streamof bits over a physical mediumNetwork InterfaceProtocolsFigure 11.2The ISO protocol stack modeladds data to the communications stream to carry out that duty.
A packetof information at the application level is sent to the presentation layer.The presentation layer augments the data in some way, usually byadding information to the packet, and sends it on to the session layer.This continues until the packet reaches the bottom layer, the physicalhardware.
At this point, the data stream is sent to its destination and thephysical hardware of the destination computer receives the stream. Nowthe process begins in reverse. As the data packet is received by eachlayer, that layer strips off the data it needs, using the data to performsome function.
Then what is left is sent up the stack to the next layer.By the time the packet reaches the application layer, it is comprised ofapplication data only. The effect of this type of data transfer is that eachlayer has the illusion that it is talking directly to its counterpart layer onthe destination computer.There are many examples of this way to characterize system communications. The Wireless Access Protocol (WAP) stack, shown in Figure 11.3,has a stack-based depiction. The Bluetooth protocol stack, shown inFigure 11.4, has this type of specification as well. In all cases, regardlessof how complicated the protocol stack, the idea of moving through thestack and adding functionality to communications data applies.234MODELING COMMUNICATIONSWAE: Wireless Application EnvironmentWSP: Wireless Session ProtocolWTP: Wireless Transaction ProtocolWTLS: Wireless Transport Layer SecurityWDP: Wireless Datagram ProtocolBearer Layer: GSM, CDMA, CDPD, iDEN, etc.Figure 11.3 The WAP protocol stackThere are several advantages to this stack-based approach.
The first issomething we have just mentioned: each layer can maintain an illusionthat it is communicating solely with the same layer on another computer.Another advantage is modularity. Each layer in the communicationsmodel can be implemented by a module of some sort. That module canbe built to serve only a specific function, implementing a specific layer inthe stack. As with all modular software components, this type of designTCSBINOther transportprotocolsSDPRFCOMMLMPL2CAPAudioBasebandBluetooth RadioFigure 11.4 The Bluetooth protocol stackCOMMUNICATIONS MODELS235enhances the ability to modify only certain parts of the communicationsstack without affecting other parts. If, for example, an operating systemwere to start using IPv6 instead of IPv4 in the implementation of Ethernetnetworking, the network layer could be removed and reworked, leavingthe other layers alone.Communications AbstractionsAnother way to look at communications is to consider the abstractionsthat operating systems employ to address it.
Abstractions are often usedby operating systems to allow users to encapsulate many details into aconcise model. This concise model, while hiding many details, helps tounderstand operating system functions better.SocketsWe looked at sockets in Chapter 6 as a means of interprocess communications. Sockets are often used in general to depict the communicationsbetween computers.By way of review, sockets were invented by the designers of BerkeleyUnix and were first used as an ‘endpoint for communications’ to accessnetwork protocols. As an endpoint, a socket is not very useful.
Butwhen connected to a socket on another computer, the pair becomes acommunications channel that uses a protocol to transfer data. You canthink of sockets as two ends of a conversation and the protocol as thetranslator.Sockets assume a client–server model. The client connects its endof the socket and makes a request to the server for connection. Theserver either connects up its end and replies positively or replies thatno connection can be made. Then, if the socket has been successfullyconnected, data is exchanged across the socket.The socket model is useful as a communications model because of itsabstractness and its depiction of translation abilities.
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.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
