Wiley.Symbian.OS.C.plus.plus.for.Mobile.Phones.Aug.2007 (779890), страница 51
Текст из файла (страница 51)
The followingcode snippet illustrates the use of RMsgQueue to create a global, namedmessage queue.Class TMyMsg{public:TInt iFirst;TInt iSecond;}...RMsgQueue<TMyMsg> tmpQ;TInt err = tmpQ.CreateGlobal(KMyQueueNameLit, KMyQueueSlots, KSlotSize);Using a Message QueueYou need a handle to a message queue before you can read from, orwrite to, it. In the case of a global, named message queue, any processcan open it by name:TInt openErr = iQueue.OpenGlobal(KMyQueueNameLit);To use the other types of message queue, you need to obtain a handlefrom the process or thread that created the queue.Once you have a handle for a queue, preferably as an RMsgQueueinstance, then you can send (or receive) messages, for example:TInt sendErr = iQueue.Send(iSmallMsgType);if (KErrOverflow == sendErr){DecideWhatTodoWhenQueueIsFullL();}If you do not wish to handle the case where the queue may be fullfor sending (or empty for receiving) a message, then you could use theblocking family of calls, such as:iQueue.SendBlocking(iSmallMsgType);Bear in mind that this type of call cannot be canceled and no otherwork can be performed by the calling thread until the call returns.
Ifthis would have an impact on your thread’s concurrency requirements,WHICH IPC MECHANISM SHOULD YOU USE?259you should use an active object to make calls to the message queue’sasynchronous functions NotifyDataAvailable() (for receiving messages) and NotifySpaceAvailable() (for sending messages), andperform the appropriate Receive() or Send() in the active object’sRunL().8.5 Which IPC Mechanism Should You Use?Client–serverWhen using the client–server mechanism, the relationship between theparticipants is clear: the client has to initiate requests that the server hasto service.
Moreover, the server may receive such requests from manyclients, in which case requests are serialized and completed one at a time.There are no deterministic guarantees in this scenario and a ‘connection’has to be set up for every communication channel.This mechanism is ideal for the case where some kind of resource, withinherently serial access, is offered to many clients simultaneously. Thusthe server’s responsibilities are to mediate access to resources throughpre-defined service interfaces.Publish and SubscribePublish and subscribe is probably the most important new IPC mechanismand the one with the most impact.
It was created to solve the problem ofasynchronous multicast event notification and to allow for connectionlesscommunication between threads.With this new API, interested parties do not need to know who the eventprovider is. This design is essential in avoiding having many componentsknowing about many other components and having to connect to them,just to discover and consume events. Thus this API breaks the need toknow about, and link to, many client APIs; participants only need toknow about the P&S API and the properties they are interested in.Producers and consumers of events can dynamically join and leavethe ‘conversation’ without any prior commitment or connection setup.This paradigm lends itself perfectly to agent-type scenarios, where bothasynchronicity and autonomy are essential.
Architecturally, for developers, this is very significant, since their components can be designedand deployed without any prior knowledge of who their consumers orproducers may be; nor need they supply interfaces to them other thanthe specification of the properties in question. Effectively, publishers andsubscribers are completely shielded from each other. This is the reasonwhy multicasting is so easy and comes for free.We refer to the publication of events in Publish and subscribe as‘multicasting’ instead of ‘broadcasting’ because it does not have to260INTERPROCESS COMMUNICATION MECHANISMSpollute the communication channels of every thread unless we wish itto.
Publish and subscribe is the best paradigm to multicast events tointerested parties without the need to know explicitly who, where or howthese parties receive these events and without having to involve them ifthey are not interested.Accounting and resource management is handled by the kernel andthus the complexity of usage is kept really low.
Consequently, althoughdelivery to and from the kernel in this mode of communication isguaranteed and deterministic, messages are not guaranteed in termsof their timely reception from remote parties. This is because remoteparties may not be interested in the communication or may not evenexist – and there is no pre-defined way to know (other than out-of bandcommunication between the parties) of their interest or existence.It is therefore advised that P&S should be used when a componentneeds to supply (or consume) timely but transient information to (or from)an unknown number and kind of interested parties, while maintainingmaximum decoupling from them.Typical scenarios would be the dissemination of battery status information across the system and the publication of the status of communicationlinks.
In general, whenever such contextual information is to be communicated across the system, P&S is the paradigm to use.Message QueuesThe Message Queue API allows designers to break the connection, whilekeeping the communication, between two or more threads. In that sense,two threads may communicate with one another without needing to setup connections with each other. In effect, this breaks the synchronicity inthe setting up and tearing down of connections as well as removing theneed for the rendezvous of these threads for such setup to take place.Breaking such connection synchronicity has many benefits for scenarios where, otherwise, deadlocks could arise in using the client–serverparadigm.
Such deadlocks manifest themselves during cancellation orsetup of sessions between clients to servers which are themselves clientsto other servers, when not properly coded.This form of IPC is less alien to developers porting from other operatingsystems to Symbian OS, where similar mechanisms (such as mailboxes)exist.As outlined above, a queue allows for many senders to communicatemessages. The ultimate recipient of messages is not known in a globalqueue, since any thread may read from it. Consequently, delivery to thefinal recipient is not guaranteed. For such a guarantee to be possible,participants have to agree on an implicit protocol where a queue may beaccessed from only one reader. This is Symbian’s recommendation forthis IPC for almost all cases. It has to be noted that messages are sent toSUMMARY261queues and not to final recipient threads.
Therefore, messages don’t haveany header payload stating their final destination.Symbian OS message queues are not pipes. To emulate pipes inSymbian OS using the Message Queue API, one has to build a protocoland abstractions on top of the API. Since messages are anonymousand don’t have delivery addresses, queues may be used as half-duplexpipes. It is down to the communicating threads to define this protocolbetween them and to set up the two queues necessary for peer-to-peercommunication between them.When this is done, two threads may asynchronously communicatewith each other without necessarily linking to each other or to client APIsother than the Message Queue API. This is beneficial since (componentsand) threads become replaceable at run time to be either senders orreceivers of messages from a queue. Thus high-availability services canbe offered, and be serviced at run time, without disrupting their clients.QueueThread BThread AQueueKernel spaceFigure 8.6 Message queues (used as half-duplex pipes)P&S is excellent for notifications of state changes that are inherentlytransient but queues are good for communicating information that transcends the sender’s state or lifetime.
For example, a logging subsystemcould utilize a queue to receive messages from many threads that mayor may not be running at the point where the messages are read andprocessed. In that sense, a service provider in this paradigm (as opposedto client–server) is not the one which mediates (and disseminates) datafrom the resource, but is the one which consumes the data.SummaryThis chapter has examined the interprocess communication (IPC) mechanisms available to applications and servers in Symbian OS:• client–server IPC• publish and subscribe IPC• message queue IPC.9Platform Security and PublishingApplicationsThis chapter deals with preparing your application for distribution. Wediscuss information related to building an application for, and runningit on, a target machine, including giving your application an icon andbuilding a distributable SIS file from a PKG file.
There is also an introduction to platform security, so that you can successfully prepare yourapplication for the Symbian Signed program.9.1 Releasing an ApplicationIn order to release your application, some important steps must betaken. These steps do not require you to add more C++ code, but areconsidered critical to ensuring the success of an application in the massmarket.
The extra work involved focuses on things such as preparingan icon for the application, building it as an installable applicationand authorizing it under the Symbian Signed program. The last step isespecially important with the introduction of platform security in SymbianOS v9.Symbian OS v9 is a major evolution. It is specifically geared to targetmid-range phones in tens and hundreds of millions of units – offering evenlarger opportunities for developers to market their products.
As such, itincludes a significant number of new features and improvements to enablekey emerging technologies required by advanced, open mobile phonesfor years to come. In order to provide comprehensive support for newfunctionality such as Digital Rights Management, Device Managementand Enterprise-grade data handling, large changes have been made to the264PLATFORM SECURITY AND PUBLISHING APPLICATIONSvery core of Symbian OS to support vital concepts such as data protectionor ‘caging’ and restricting some API usage.9.2 How Does Platform Security Work?The platform security enhancements represent an evolution of the perimeter security model of Symbian OS v8 and help ensure the stabilityof the platform. They provide greater protection against malicious orbadly implemented applications, by operating at the software levelto:• detect unauthorized access attempts to hardware, software or datawhich may lock up the phone or affect other software or the network• prevent applications from acting in unacceptable ways, irrespective ofwhether these actions are intentional (i.e.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
