Smartphone Operating System (779883), страница 52
Текст из файла (страница 52)
This is a simple interface that all user code interactions gothrough. Note that this class is used no matter if the device is the display,a Bluetooth transmitter, or an infrared port. This provides a layer ofabstraction that results in a consistent interface to the physical device.The PDD provides the connection to the physical device. It interfaceswith the LDD using an interface designed by the LDD.As an example of this division of responsibilities, consider the serialinterface. There are several serial-device types that can be connected toa Symbian OS device. The IR port and the RS232 port are both serialdevices and can use the same generic serial LDD, called ECOMM.LDD.These ports are serial ports and use the same policies with respect toissues such as flow control. However, their PDD modules are different:one services the RS232 port and one services the IR port.
Other examplesinclude the Ethernet driver (ENET.LDD and ETHERNET.PDD) and thesound driver (ESOUND.LDD and ESDRV.PDD).Chapter 9 contains more information about device drivers and kernelextensions. There are many more details about these items that are notrelevant here.The protocol-implementation layerSeveral sublayers have been added to the protocol-implementation layer.Four types of module are used for protocol implementation.COMMUNICATIONS ON SYMBIAN OS241• CSY modules : the lowest level in the protocol implementation layeris the communications server.
A CSY module communicates directlywith the hardware through the PDD portion of the device driver,implementing the various low-level aspects of protocols. For instance,a protocol may require raw data transfer to the hardware device orit may specify 7-bit or 8-bit buffer transfer. These ‘modes’ would behandled by the CSY module. Note that CSY modules may use otherCSY modules. For example, the IrDA CSY module that implementsthe IrCOMM interface to the IR PDD also uses the serial device driver,ECUART CSY module.• TSY modules : telephony comprises a large part of the communications infrastructure and special modules are used to implement it.The telephony server (TSY) modules implement the telephony functionality.
Basic TSYs may support standard telephony functions, e.g.,making and terminating calls, on a wide range of hardware. Moreadvanced TSYs may support advanced phone hardware, e.g., thosesupporting GSM functionality.• PRT modules : the central modules used for protocol implementation,protocol (PRT) modules, are used by servers to implement protocols. Aserver creates an instance of a PRT module when it attempts to use theprotocol. The TCP/IP suite of protocols, for instance, is implementedby the TCPIP.PRT module.
Bluetooth protocols are implemented bythe BT.PRT module.• MTMs : as Symbian OS has been designed specifically for messaging,its architects built a mechanism to handle messages of all types. Thesemessage handlers are called message type modules (MTMs). Messagehandling has many different aspects and MTMs must implementeach of these aspects.
User-interface MTMs must implement thevarious ways users view and manipulate messages, from how auser reads a message to how a user is notified of the progress ofsending a message. Client-side MTMs handle addressing, creating andresponding to messages. Server-side MTMs must implement serveroriented manipulation of messages, including folder manipulationand message-specific manipulation.These modules build on each other in various ways, depending on thetype of communications that is being used.
Implementations of protocolsusing Bluetooth, for example, use only PRT modules on top of devicedrivers. Certain IrDA protocols do this as well. TCP/IP implementations242MODELING COMMUNICATIONSthat use PPP use PRT modules, a TSY module and a CSY module. TCP/IPimplementations without PPP typically do not use either a TSY module ora CSY module but link a PRT module directly to a network device driver.The WAP protocol stack uses a WAP PRT on top of an SMS PRT, whichin turn is built on a GSM TSY and some kind of CSY (ECUART, IrCOMM,or RFCOMM).Infrastructure modularityWe should take a moment to appreciate the modularity of the stackbased model used by the communications infrastructure design. The‘mix and match’ quality of the layered design should be evident fromthe examples just given.
Consider the TCP/IP stack implementation. APPP connection can go directly to a CSY module or choose a GSM orregular modem TSY implementation, which in turn goes through a CSYmodule. When the future brings a new telephony technology, the existingstructure works and we only need to add a TSY module for the newtelephony implementation. In addition, fine-tuning the TCP/IP protocolstack does not require altering any of the modules it depends on; wesimply tune up the TCP/IP PRT module and leave the rest alone. Thisextensive modularity means new code plugs into the infrastructure easily,old code is easily discarded and existing code can be modified withoutshaking the whole system or requiring any extensive reinstallations.Finally, Figure 11.6 has added sublayers to the application layer. Thereare CSY modules that applications use to interface with protocol modulesin the protocol implementations.
While we can consider these as parts ofprotocol implementations, it is a bit cleaner to think of them as assistingapplications. An example here might be an application that uses IR tosend SMS messages through a mobile phone. This application would usean IRCOMM CSY module on the application side that uses an SMS implementation wrapped in a protocol-implementation layer. Again, the modularity of this entire process is a big advantage for applications that needto focus on what they do best and not on the communications process.11.3Communications on Other Operating SystemsSymbian OS is a great example of the way that most other operatingsystems model communications. Figure 11.6 is a good way to depictthe application of I/O concepts to communications in other operatingsystems.COMMUNICATIONS ON OTHER OPERATING SYSTEMS243Device drivers are the way operating systems tie physical communications-hardware devices into the system.
Every device is different, butevery device must eventually be presented in a standard way. Thismeans that devices must speak to the operating system via some kindof ‘translator’, and that translator is the device driver. Device driversare typically loaded dynamically when their intermediary services areneeded, much like the drivers for other types of device I/O (discussed inChapter 9).The protocol implementation for an operating system is a good exampleof the stack model of communications. Most implementations of communications form a stack, as we demonstrated with Symbian OS.
Asdiscussed in Chapter 9, abstraction plays a big role here. While thesame API is in often place, the implementation functions are dynamicallyloaded when they are needed.Consider, for example, the code below, which is for a generic Linuxserver that accepts a socket connection from a client and reads andprocesses the client’s request across the socket.void main(int argc, char **argv){/* Declarations for sockets */int sockfd;int result, select;int readfds[32];struct sockaddr_in sin;int msgsock;char recv_buffer[256];/* Step 1: Create the socket. */sockfd = socket (AF_INET, SOCK_STREAM, 0);if (sockfd < 0){(void) perror ("socket creation");exit(-1);}/* Step 2: Data setup */sin = (struct sockaddr_in *) & salocal;memset ((char *) sin, "\0", sizeof (salocal));sin->sin_family = AF_INET;sin->sin_addr.s_addr = INADDR_ANY;sin->sin_port = 1100;/* Step 3: Bind the socket to the network */result = bind (sockfd, & salocal, sizeof (*sin));244MODELING COMMUNICATIONSif (result < 0){(void) perror ("socket binding");exit(-1);}/* Step 4: Set up listening on the socket */listen(sockfd,5);for(;;) {FD_ZERO(&readfds);if(sockfd >= 0) FD_SET(sockfd, &readfds);/* Step 5: Wait for input on the socket */status = select(32, &readfds, NULL, NULL, NULL);if(status == -1){if (errno == EINTR) continue;exit(101);}if((sockfd >= 0) && FD_ISSET(sockfd, &readfds)){DEBUG("Setting up the MSG SOCKET\n");/* Step 6: GOT input, accept it, creating a file descriptor.
*/msgsock = accept(sockfd, 0, 0);/* At this point, we have a file descriptor (msgsock) that wecan read and write to. NOW we process the data that comesover the socket.Step 7: Process input. */result = read(msgsock, recv_buffer, (int) sizeof(recv_buffer));if(result > 0){result = process_cmd(recv_buffer,msgsock);close(msgsock);}}}}Each system call addresses some part in the stack. Step 1 creates asocket, unbound but with a definition (it is a TCP/IP network socket,AF_INET, to be opened over TCP, SOCK_STREAM). Step 3 pushes a bitdeeper into the stack, using the data set up in Step 2 to bind the filedescriptor to an entry in a system table connected with networks.
Thisbind() call implies that a read or write takes place and loads the codenecessary to connect the read or write with the data on a network. Beforebind(), a socket is just a file descriptor; after bind(), it is a descriptorEXERCISES245tied to a specific implementation of read and write system calls. Step 4activates network listening for requests, using read() and write()calls to engage in socket protocols with the other side of the networkconnection.
At the end of this call, the device driver has been loaded andis actively working with the network port to process network data. Step 5is a blocking call that waits until some file descriptor has data on it. Again,notice the abstraction in this call. The select() call takes a collectionof file descriptors of all kinds and returns when at least one has data. Thatimplies that all the descriptors must have the same interface (read/write).When the call returns, we assume that the socket we have set up as a filedescriptor has data waiting.
Step 6 accepts that data, deriving a regulartwo-way socket from the server socket. Step 7 begins receiving data.This example illustrates the abstraction and modularity built into thestack model of communications. It combines a client–server approachwith stack-oriented implementations and sockets to give us an effectiveway of describing network service. These models have proved so usefulthat they are built into most modern operating systems in use today.11.4SummaryThis chapter has discussed the types of models that operating systemsuse to characterize communications.
Abstraction is the key to using thesemodels. We discussed how client–server relationships are built and howimplementation stacks use abstraction to connect system calls together.We described how the ideas of sockets and event-driven communicationsprovided mechanisms to understand implementation details. We thengave examples of these models from both Symbian OS and Linux.Exercises1.We stressed many different uses for abstraction in this chapter. Findthem and describe why each one is useful.2.Client–server relationships can be found in many places in an operating system.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
