Smartphone Operating System (779883), страница 59
Текст из файла (страница 59)
First, we must create a session with the message server. Next,we must initialize contact with the message-system registry in such a waythat we can create MTMs later to handle messages. Finally, we access themessage system by walking through the message structure tree: we accessthe system root, then find the message’s service, then the message’s folder(and possibly subfolders), and then we access the message.A session with the message server is initiated by system calls from theclient. Sessions can be opened synchronously or asynchronously.After establishing a server session, the next step is to open the registryso that we can access MTM objects when we need them. There are threekinds of access into the registry: one to access client-side MTMs, one toaccess user-interface MTMs, and one to access user-interface-data MTMs.Each access is implemented by its own class and their own system calls.They are derived from the same base classes and have similar definitions.Once we have a valid message-server session established and we haveaccess to the registry, we can access the message-tree structure.
Let’s lookat the characteristics of an entry in the message tree. An entry includesthe following properties:• an entry ID• the header information• an ‘owning service’, i.e., the parent of an entry• a certain number of children (for the root and inner-tree nodes)• file storage• an MTM list.280MESSAGINGBehind the ScenesStop for a moment and consider what is going on behind the scenesof remote-message transfer. The implementation of this is different fordifferent message types.Consider a session with a remote email server.
The local device’s copyand move operations access the server through the existing socket andpass commands to the server through this socket. These operations donot need additional connections as one already exists.Finally there are implementations of different MTMs, which includefunctions that are specific to each MTM and do not generalize to allMTMs. For example, an email-message MTM that uses POP3 wouldneed functions to connect to and disconnect from the POP3 server. ABIO-message MTM would not need a function to connect to a serverbecause there is no server for BIO messages (they are pushed to a device).On the other hand, a BIO-message MTM needs a function to process theBIO-message content.
This applies to SMS and fax messages as well. EachMTM implementation requires its own system calls.The messaging architecture provides a way for MTM components tooffer protocol-specific functionality not provided by base-class-interfacefunctions. These MTM-specific functions are implemented in the MTMand assigned IDs that correspond to each protocol-specific operationoffered.Easy Sending of Messages: Send-As MessagingBy now you might be a little taken aback by the complexity of messagehandling and the message architecture of Symbian OS.
While it is true thatthe architecture is big and complex – after all, it must handle messages asdifferent as faxes and SMS messages – the designers of Symbian OS havestreamlined the process we use to send messages. The sending process isrelatively short and very straightforward. Let’s review that process in thissection.The sending procedure is called send-as messaging. It is a genericprocess – i.e., one process for all message types – that uses a messagetype’s MTM to guide the sending process. It is a powerful model that canbe used to send messages of all types and even to transfer data in uniqueways. The procedure follows the sequence we outlined in the last section.Send-as messaging centers on the CSendAs class and is accomplishedby the following steps:MESSAGE HANDLING IN LINUX2811.Choose the MTM that the CSendAs object uses to send the message.This can be done in two ways: we can set the MTM directly or wecan use a CSendAs object to search for the MTM we need.2.Choose the service to use for the outgoing message.3.Create the message (and all its parts) as a CSendAs object.
Once themessage for the CSendAs object has been created, we can createand modify its components: the recipients, the subject, contents ofthe body, and so forth.4.Save and send the message means saving it into the appropriateservice’s message store.Receiving MessagesApplications can work with the messaging system and message arrival.While the message server itself handles the listening and messagetransport functions, applications can register themselves to be notifiedupon message arrival.Registration occurs when a connection with the message server isestablished. Recall that connecting with the message server requires aparameter that is an object of the MMsvSessionObserver class.The message server calls a specific function from the class objectpassed during the server connection whenever a ‘message event’ occurs.A code that signifies which event occurred is passed in the first parameterand up to three pointers to data areas that apply to the message eventmake up the rest of the function call’s parameter list.13.3Message Handling in LinuxWhere messaging may seem quite complex on Symbian OS, it is positivelysimple on Linux.
As an illustration and contrast, let’s overview howmessages are handled by the Linux operating system.Message Models in LinuxAs we have seen before, Linux designers usually take the simplest routethey can when dealing with complex situations. Messaging is no exception. There is little built-in support for messages or message types in theLinux kernel. Any message modeling or message structure must be built282MESSAGINGand configured by applications or by third-party developers designingmodules for Linux.
Email messages represent an exception: there is somesmall support for email in Linux.Linux message structure is quite straightforward. Text files representemail messages; any other kind of messages are built and used by theapplications that implement them. Even attachments to email requiremessage-processing programs supplied outside of the operating system.Linux supplies the mechanism to receive messages and place them in afile. Any reading of messages must access the message file and processthat file in a way appropriate to the message type.In a sense, this approach to messages utilizes abstraction – except thatit is not built into the operating system.
Linux supplies the base operationand assumes that any further processing is provided by an outside source.In like manner, Symbian OS provides the base processing and assumesthat further processing of a message is supplied by outside MTMs. Themajor difference between these two is the lack of a model in Linux. Linuxsimply assumes that applications are provided to process the text filemessage that has just been received.Sending MessagesThe communications medium over which messages travel is a sharedresource in Linux.
Whether it is a network or a Bluetooth connection,Linux usually provides a server that shares the resource between theprocesses that require it.The reasoning for these Linux servers, however, is a bit different thanthe reasoning behind servers in a microkernel operating system likeSymbian OS. For Linux, servers implement protocols.
These protocolsare complicated enough that a server is designed to handle the complexnature of the communication. The server implementation is an assistantto developers that want to use the resource, but that is all. The serverdoes not protect the resource; in fact, if an application were to want touse the resource, the system would gladly allow the access. This meansthat, while sending messages in Linux is aided by opening a connectionto a server, that connection is not technically necessary.However, sending messages in Linux is helped by various messageservers. Consider email.
There are several email servers that run underLinux; a popular application for this service is the ‘sendmail’ server.A sendmail server receives an email message from a client, processesthat message by reviewing the textual message contents and opens aSUMMARY283connection to a remote server by way of delivering the message. There isno special format other than the format of an email message itself (whichis public-domain specification).There is nothing special about an email server.
In fact, if an emailclient wanted to send its email directly to the receiver’s email server,it could certainly do so. The network connection would be shared bythe operating system through the abstraction of sockets. The ‘sendmail’process could easily be bypassed.Receiving and Delivering MessagesAs you might expect from a Linux system, receipt and delivery of messagesis very simple as well. The computers that are configured to receivemessages run a server that listens for incoming messages, receives thosemessages and stores them.
Again, a server is used because it is convenientnot because it is managing the shared communication medium.Email again makes a great example. The ‘sendmail’ server processesincoming messages as well as outgoing messages. It listens for connections – as it always does – and delivers messages to local as well asremote computers. Notice that this action is the same action we discussedin the last section. The server’s actions are very straightforward – receivea message, determine the destination, and either send it on or store itlocally. Local storage is as a text file.Sometimes the simplicity of Linux is a liability.
The simplicity of‘receive a message’ and ‘deliver a message’ has degraded system securityin the past. A practice called relaying is used to send an email from anoutside party to an outside party. This would not be such a bad practicewere it not for spam email or unsolicited email. Often, a relayed messagecomes into an email server with 100s of email addresses as destinations.The resulting delivery is not only a burden on the delivery server, butit also shields the sender’s address. Relaying is a practice that is on thedecline, mostly because of new verification mechanisms built into Linuxemail servers.13.4SummaryIn this chapter, we have discussed the messaging frameworks of operatingsystems.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
