WO2010073208A1

WO2010073208A1 - Communication using a message queue

Info

Publication number: WO2010073208A1
Application number: PCT/IB2009/055871
Authority: WO
Inventors: John Forrest; James Ingham; James Curry; Rhod Byles
Original assignee: Nokia Corporation
Priority date: 2008-12-22
Filing date: 2009-12-21
Publication date: 2010-07-01
Also published as: GB2466314A; GB0823351D0

Abstract

A method of communicating between a source (14) and a destination (12) uses a message queue (16) which is common to the source (14) and the destination (12). The method includes placing a message from the source (14) intended for the destination (12) in the message queue (16), retrieving the message from the message queue (16) at the destination (12) and preventing execution of a message placed in the message queue (16) prior to the retrieved message if the retrieved message invalidates the prior message.

Description

COMMUNICATION USING A MESSAGE QUEUE

BACKGROUND

[01] It is common for different elements of a computing system, such as client and server software components running in different threads on a processor, to communicate with each other using a message queue. The message queue provides an asynchronous communication mechanism, such that the sender (the server in this example) and receiver (the client in this example) of a message need not access the message queue at the same time. Instead, a message, which may be a control signal, data or other content, is placed in the message queue by the server and remains in the queue until it is retrieved by the client.

[02] A problem can arise with this system when the server places a message in the message queue and this message is rendered invalid before it is retrieved by the client as a result of an action taken by the client. For example, the client may send a "Stop" message to the server before it has retrieved a "Buffer Request" message sent by the server from the message queue, as is illustrated in Figure 1. The "Stop" message sent by the client to the server invalidates all previous messages in the message queue. However, when the "Buffer Request" message is retrieved by the client, it has no way of discerning if the "Buffer Request" message was sent before or after the "Stop" message, and so may try to act on it, which may cause a software error or crash.

[03] One solution to this problem is to force the client to issue an acknowledgement message every time it receives a message from the server. This enables the server to discern if the client has received the message, and thus the server can take action if a message is received which invalidates a previously sent message which has not yet been retrieved by the client, such as removing the now-invalid message from the message queue. However, this solution has a number of disadvantages. It increases the number of messages sent between the server and the client, which may reduce the operating speed of the system using the message queue. Additionally, the server must wait until it receives an acknowledgement message from the client before taking any action, which could also reduce the operating speed of the system. Moreover, if the client fails to issue an acknowledgement message because of an error, software failure or the like, the sender may freeze, as it is unable to take any further action until an acknowledgement message is received.

SUMMARY

[04] At least some embodiments include a method of communicating between a source and a destination using a message queue which is common to the source and the destination. The method comprises placing a message from the source intended for the destination in the message queue, retrieving the message from the message queue at the destination and preventing execution of a message placed in the message queue prior to the retrieved message if the retrieved message invalidates the prior message. This method can overcome problems outlined above without requiring additional acknowledgement messages to be sent by either the source or the destination. Thus, unlike prior art methods, this method does not adversely affect the operating speed of the system in which it is implemented.

[05] Preventing execution of the prior message may comprise removing the prior message from the message queue.

[06] A filtering operation may be performed to remove the prior message from the message queue.

[07] The filtering operation may comprise inserting a marker into the message queue at the next available position, retrieving each message in the message queue in turn, assessing the validity of each retrieved message and discarding any retrieved message that is found to be invalid.

[08] Preventing execution of the prior message may comprise removing all messages received prior to the retrieved message from the message queue

[09] The prior message may be removed from the message queue by the destination. [10] The message from the source may comprise an identifier and preventing execution of the prior message may comprise ignoring the prior message if the identifier of the retrieved message does not correspond to an identifier of the prior message.

[11] The prior message may be placed in the message queue by the destination.

[12] The prior message may comprise a further identifier generated by the destination.

[13] The source may comprise a client and the destination may comprise a server.

[14] At least some embodiments include one or more machine-readable media that store instructions executable by one or more processors to so as to perform a method according to various other embodiments.

[15] At least some further embodiments include an apparatus or other system comprising a message source, a message destination and a message queue, the message source being configured to place a message destined for the message destination in the message queue and the message destination being configured to retrieve the message from the message queue, wherein the apparatus is configured to prevent execution of a message placed in the message queue prior to the retrieved message if the retrieved message invalidates the prior message.

[16] The apparatus may be configured to prevent execution of the prior message by removing the prior message from the message queue.

[17] The apparatus may be configured to perform a filtering operation to remove the prior message from the message queue.

[18] The apparatus may be configured to insert a marker into the message queue at the next available position, retrieve each message in the message queue in turn, assess the validity of each retrieved message and discard any retrieved message that is found to be invalid. [19] The apparatus may be configured to prevent execution of the prior message by removing all messages received prior to the retrieved message from the message queue

[20] The destination may be configured to remove the prior message.

[21] The message from the source may comprise an identifier and the apparatus may be configured to prevent execution of the prior message by ignoring the prior message if the identifier of the retrieved message does not correspond to an identifier of the prior message.

[22] The destination may be configured to place the prior message in the message queue.

[23] The destination may be configured to generate a further identifier which is allocated to the prior message.

[24] The source may comprise a client and the destination may comprise a server.

Brief Description of the Drawings

[25] Embodiments will now be described, strictly by way of example only, with reference to the accompanying drawings, of which:

[26] Figure 1 is a schematic illustration showing a client and a server communicating using a message queue.

[27] Figure 2 is a schematic illustration showing components of a system for implementing a method according to some embodiments.

[28] Figure 3 is a schematic illustration showing a client and a server communicating using a message queue in accordance with some embodiments.

[29] Figure 4 is a flow diagram illustrating steps performed to remove an invalid message from a message queue. [30] Figure 5 is a schematic illustration showing a client and a server communicating using a message queue in accordance with an alternative embodiment.

[31] Figure 6 is a schematic illustration showing a client and a server communicating using a message queue in accordance with a further alternative embodiment.

[32] Figures 7-9 are block diagrams of systems according to various embodiments.

DETAILED DESCRIPTION

[33] Referring now to Figure 2, a system for communicating between client and server software components running in different threads on a processor is shown generally at 10. As is known in the art, processors are configured to execute instructions (which instructions may include executable code and/or hard-wired logic) to carry out desired operations. In the embodiment of Figure 2, the processor is configured to execute instructions so as to carry out the operations of server component 12 and client component 14 described herein. As described below, server component 12 and client component 14 each accesses a message queue 16, and thus the processor of Figure 2 also includes (or accesses) a memory on which data of queue 16 can be stored. Although embodiments will be described with reference to this system as shown in Figure 2, it will be understood that other embodiments encompass any system where communication between components is achieved using a message queue. For example, techniques described herein may be used in general purpose computer networks and the like. Accordingly, and as is also explained in more detail below, a system according to various embodiments can be a single apparatus or device (e.g., a single processor, a mobile terminal) or can include multiple apparatuses or devices (e.g., multiple processors and/or memory units in a single product, multiple computers in a network).

[34] The system 10 includes a server component 12 and client component 14 which communicate by placing messages in a message queue 16 which is common to the server component 12 and the client component 14. Communication between the server component 12 and the client component 14 is asynchronous, meaning that the server component 12 and the client component 14 need not access the message queue 16 at the same time. Instead, the server component 12 and the client component 14 place messages in the message queue 16, and these messages are retrieved by the other component at some later time.

[35] The operation of one embodiment of the invention is illustrated schematically in Figure 3. In this example, the server 12 and the client 14 are components of an application programming interface (API) providing audio functionality which run in different threads on a processor of a computing device such as a mobile telephone. However, it will be appreciated that the approach described below is equally suited to any client-server communication which uses a message queue.

[36] At a time 20 the client 14 places a first "Play" message in the message queue 16, to initialise playback of an audio file. In response, the server 12 places a first "Buffer Request" message in the message queue at time 22, to request data from the client 14 to fill a buffer in which the audio file will be stored and from which playback will occur. At time 24, before the server's first "Buffer Request" message has been retrieved by the client 12, the client 12 places a "Stop" message in the message queue 16. This "Stop" message renders the first "Buffer Request" message invalid. On receiving the "Stop" message at time 26, the server 12 removes the first "Buffer Request" message from the message queue 16. Thus, the client 14 never receives the now-invalid first "Buffer Request" message and is prevented from acting upon it.

[37] At a time 28, the client 14 places a new "Play" message in the message queue 16 to instigate playback of an audio file. This new "Play" message is received by the server 12 which responds by placing a new "Buffer Request" message in the message queue 16 to request data from the client 14. No further messages are issued by the client 14 before it retrieves this new "Buffer Request" message at time 30, so the new "Buffer Request" message is valid and the client 14 acts on it to provide the requested data.

[38] In certain systems, the first "Buffer Request" message can simply be removed from the message queue 16 by the server 12, by using a unique identifier of the message for example. However in some systems the first "Buffer Request" cannot be identified and removed in this way, and a process of filtering must be implemented to remove the invalid message from the message queue 16 whilst leaving valid messages in the message queue 16. One process for filtering the message queue 16 in this way is described below, with reference to the flow diagram of Figure 4.

[39] In step 40, the server 12 places a "Special Marker" message in the message queue 16 at the next available position in the message queue 16. The server 12 then retrieves the first message (that is to say the oldest message) from the message queue 16 at step 42. The server 12 examines the retrieved message at step 44. A test is made at step 46 to determine if the retrieved message is the "Special Marker" message. If so, there are no messages in the message queue 16 and thus the process is exited at step 48.

[40] If the retrieved message is not the "Special Marker" message, a test is made at step 52 to determine if the retrieved message is valid. If so, the retrieved message is placed in the next available position in the queue at step 54 (i.e. after the "Special Marker" message), and the process returns to step 42, with the server 12 retrieving the next message from the message queue 16.

[41] If the test at step 52 determines that the retrieved message is not valid, the retrieved message is discarded at step 56 and processing returns to step 42, where the server 12 retrieves the next message from the message queue 16.

[42] The message queue 16 is processed in this way until the "Special Marker" message is retrieved, indicating that all messages in the message queue 16 have been examined.

[43] It will be appreciated that for this filtering process to work correctly, it should be carried out in isolation, such that only the server 12 is able to place messages in the message queue 16 or remove messages from the message queue 16 during the filtering process. [44] In an alterative embodiment, the server 12 may remove all messages from the message queue 16 on receiving a message from the client 14 which invalidates the previous messages. In this embodiment, on receiving such a message the server 12 retrieves and discards all of the messages in the message queue 16 that were placed there before the message that has rendered the previous messages invalid.

[45] It will be appreciated that this approach is only appropriate when a message received by the server 12 invalidates all the previous messages in the message queue 16, such as a "Stop" message. In cases where the message received does not invalidate all previous messages the filtering approach described above must be used, to ensure that valid messages are not discarded.

[46] In the embodiments described above, the server 12 is responsible, on receipt of a message which invalidates some or all of the previous messages in the message queue 16, for deleting invalid messages from the message queue 16. However, the client 14 could also perform this role, if it is authorised to do so, by deleting invalid messages from the message queue 16 once it has placed a message which invalidates previous messages in the message queue 16.

[47] The operation of an alternative embodiment of the invention is illustrated schematically in Figure 5. In this embodiment messages placed in the message queue 16 by the client 14 are allocated a unique identifier, which in this example is a serial number, but which could equally be an alphanumeric string or any other type of identifier. The serial number allocated to messages by the client 14 is incremented each time a new message is placed in the message queue by the client 14. The identifier of the last message received by the server 12 is appended to messages placed in the message queue 16 by the server 12, such that the client 14 can discern whether a message received from the server 12 is valid or not.

[48] In the example illustrated in Figure 5, the client 14 places a "Play" message in the message queue 16 at time 60. The "Play" message is allocated the serial number 100. In response, the server 12 places a "Buffer Request" message in the message queue 16 at time 62, and this "Buffer Request" bears the serial number 100, which is the last serial number received by the server 12. At time 64, the client 14 places a "Stop" message in the message queue 16. This "Stop" message is allocated the serial number 101. The "Stop" message is received by the server 12 at time 66, before the "Buffer Request" message has been retrieved by the client 14. Thus, the "Buffer Request" message is no longer valid. At time 68, the client 14 retrieves the "Buffer Request" message from the message queue 16. The client 14 compares the serial number, 100, of the "Buffer Request" message to the serial number, 101, of the last message placed in the message queue 16 by the client 14, and determines that because the serial number of the received message does not correspond to the serial number of the last message sent, the received message is invalid and should be ignored. Thus, the client 14 is prevented from executing the received "Buffer Request" message. The client 14 may remove the invalid "Buffer Request" message from the message queue 16, although this is not necessary as the invalid "Buffer Request" message has been ignored and thus will never be executed by the client 14.

[49] At time 70, the client 14 places a new "Play" message in the message queue 16, and this message is allocated the serial number 102. This message is received by the server 12 at time 72, and the server 12 responds by placing a new "Buffer Request" message in the message queue 16. The serial number 102 is appended to this "Buffer Request" message to indicate to the client 14 that it is a response to the "Play" message with the corresponding serial number. At time 76 the client 14 retrieves the new "Buffer Request" message from the message queue 16 and compares the serial number to that of the last message sent. As the serial number of the received message corresponds to that of the last message sent, the client 14 discerns that the new "Buffer Request" message is valid and is thus able to act on it by sending the requested data to the server 12.

[50] In the example described above, only the client 14 allocates identifiers to messages, with the same identifiers being used in messages sent by the server 12 in response to the messages sent by the client 14. However, in some cases it is useful for the server 12 to allocate identifiers to its messages, which identifiers are used in the messages sent by the client 14 to the server 12 in addition to the identifiers allocated by the client 14 to allow the server 12 to determine when the client 14 has processed messages sent by the server 12. Such a system is illustrated schematically in Figure 6.

[51] In this example, the client 14 places a "Play" message in the message queue 16 at time 80. This message is allocated the serial number 100 by the client 14. The "Play" message is received by the server 12, which responds by placing a "Buffer Request" message in the message queue 16, at time 82. As well as the serial number of the "Play" message, 100, this "Buffer Request" message also includes the serial number 500 allocated by the server 12.

[52] At time 84, the client 14 places a "Stop" message in the message queue 16, which invalidates all previous messages in the message queue 16. This message is allocated the serial number 101 by the client 14. At time 84, the "Buffer Request" message placed in the message queue 16 by the server 12 has not been received by the client 14. Thus, only the serial number 101 allocated by the client 14 is included in the "Stop" message. The "Stop" message is received by the server 12 at time 86.

[53] At time 88 the client 14 retrieves the "Buffer Request" message from the message queue 16. As the serial number 100 reflected by the server 12 does not correspond to the last transmitted serial number, 101, known to the client 14, the client 14 is prevented from executing the "Buffer Request" message and thus takes no action in relation to the message.

[54] At time 90 the client 14 places a new "Play" message in the message queue 16. At this time the client 14 has received the "Buffer Request" message sent by the server 12, so the new "Play" message includes the serial number 102 allocated by the client 14 and the serial number 500 carried by the last message received by the client 14.

[55] At time 92 the server 12 receives the "Play" message and compares the serial numbers to that of the last message sent by the server 12. As the serial number 500 corresponds to the serial number of the last message sent by the server 12, the server 12 is able to execute the "Play" message, and responds by placing a new "Buffer Request" message in the message queue 16. This new "Buffer Request" message is allocated a new serial number, 501, by the server 12, and carries the serial number, 102, of the last message received by the server 12 from the client 14.

[56] By using two serial numbers in this way, both the client 14 and the server 12 are able to discern if a received message is valid, and execute or ignore the message accordingly.

[57] It will be appreciated that the embodiments described above are exemplary only, and that the methods and apparatus described herein will be applicable to a large number of other systems. For example, the server 12 and the client 14 of Figure 2 could alternatively be implemented as hardware components of a distributed computing system or computer network. This is shown in Figure 7, a block diagram of a system according to another embodiment, in Figure 7, server component 12' is implemented in a first computer 712 and client component 14' is implemented in a second computer 714. Each of computers 712 and 714 includes one or more processors and one or more memories as is customary in the art, but with those processors and memories configured to carry out the client and server operations described herein. The message queue (not shown) in the system of Figure 7 could reside on a memory of computer 712, on a memory of computer 714, or on the memory of another device. Alternatively, the server 12 and the client 14 may be embodied in a single computer program or a component of a computer program running on two or more processors (as shown in Figure 8), or in separate threads of a single processor (as shown in Figure 9). Figure 8 is a block diagram showing a processor 812 on which server 12" is running and a processor 814 on which a client 14" is running. Processors 812 and 814 could be elements of a single product. Processors 812 and 814 each includes (and/or accesses) memory and is configured to carry out operations such as are described herein. Figure 9 is a block diagram showing a processor 900 on which server 12'" and client 14'" are running. Processor 900 includes (or accesses) memory and is configured to carry out operations such as are described herein.

Claims

CLAIMS:

1. A method comprising: retrieving a message from a message queue by a destination component, wherein the message is intended for the destination component and was placed on the message queue by a source component, the message queue is common to the source and the destination components, and the destination component is executing in a processor as a program thread separate from a program thread of the source component; and preventing execution of a message placed in the message queue prior to the retrieved message if the retrieved message invalidates the prior message.

2. The method of claim 1, wherein preventing execution of the prior message comprises removing the prior message from the message queue.

3. The method of claim 2, wherein removing the prior message from the message queue includes a filtering operation to remove the prior message from the message queue.

4. The method of claim 3, wherein the filtering operation comprises inserting a marker into the message queue at the next available position, retrieving each message in the message queue in turn, assessing the validity of each retrieved message and discarding any retrieved message that is found to be invalid.

5. The method of claim 1 or claim 2, wherein preventing execution of the prior message comprises removing all messages received prior to the retrieved message from the message queue.

6. The method of any of the preceding claims wherein the prior message is removed from the message queue by the destination component.

7. The method of claim 1, wherein the message from the source component comprises an identifier and preventing execution of the prior message comprises ignoring the prior message if the identifier of the retrieved message does not correspond to an identifier of the prior message.

8. The method of claim 7, wherein the prior message is placed in the message queue by the destination component.

9. The method of claim 8, wherein the prior message comprises a further identifier generated by the destination component.

10. The method of any of the preceding claims wherein the source component comprises a client and the destination component comprises a server.

11. The method of any of the preceding claims, wherein the source component program thread is also executing on the processor.

12. The method of any of claims 1 to 10, wherein the source component program thread is executing on a different processor.

13. A machine-readable medium storing instructions executable by a processor so as to perform operations that include: retrieving a message from a message queue by a destination component, wherein the message is intended for the destination component and was placed on the message queue by a source component, the message queue is common to the source and the destination components, and the destination component is executing in a processor as a program thread separate from a program thread of the source component; and preventing execution of a message placed in the message queue prior to the retrieved message if the retrieved message invalidates the prior message.

14. The machine-readable medium of claim 13, wherein preventing execution of the prior message comprises removing the prior message from the message queue.

15. The machine-readable medium of claim 14, wherein removing the prior message from the message queue includes a filtering operation to remove the prior message from the message queue.

16. The machine-readable medium of claim 15, wherein the filtering operation comprises inserting a marker into the message queue at the next available position, retrieving each message in the message queue in turn, assessing the validity of each retrieved message and discarding any retrieved message that is found to be invalid.

17. The machine-readable medium of claim 13, wherein preventing execution of the prior message comprises removing all messages received prior to the retrieved message from the message queue.

18. The machine-readable medium of claim 13, wherein the prior message is removed from the message queue by the destination component.

19. The machine-readable medium of claim 13, wherein the message from the source component comprises an identifier and preventing execution of the prior message comprises ignoring the prior message if the identifier of the retrieved message does not correspond to an identifier of the prior message.

20. An apparatus comprising: at least one memory; and at least one processor, wherein the at least one memory and at least one processor are configured to cause the apparatus to retrieve a message from a message queue by a destination component, when the message is intended for the destination component and was placed on the message queue by a source component, the message queue is common to the source and the destination components, and the destination component is executing in a processor as a program thread separate from a program thread of the source component, and prevent execution of a message placed in the message queue prior to the retrieved message if the retrieved message invalidates the prior message.

21. The apparatus of claim 20, wherein the at least one memory and at least one processor are configured to cause the apparatus to prevent execution of the prior message by removing the prior message from the message queue.

22. The apparatus of claim 21, wherein the at least one memory and at least one processor are configured to cause the apparatus to perform a filtering operation to remove the prior message from the message queue.

23. The apparatus of claim 22, wherein the at least one memory and at least one processor are configured to cause the apparatus to insert a marker into the message queue at the next available position, retrieve each message in the message queue in turn, assess the validity of each retrieved message and discard any retrieved message that is found to be invalid.

24. The apparatus of claim 20, wherein the at least one memory and at least one processor are configured to cause the apparatus to prevent execution of the prior message by removing all messages received prior to the retrieved message from the message queue.

25. The system of claim 20, wherein the at least one memory and at least one processor are configured to cause the apparatus to remove the prior message using the destination component.

26. The apparatus of claim 20, wherein the message from the source component comprises an identifier and the at least one memory and at least one processor are configured to prevent execution of the prior message by ignoring the prior message if the identifier of the retrieved message does not correspond to an identifier of the prior message.

27. The apparatus of claim 26, wherein the at least one memory and at least one processor are configured to cause placement of the prior message in the message queue by the destination component.

28. The apparatus of claim 27, wherein the at least one memory and at least one processor are configured to cause the destination component to generate a further identifier which is allocated to the prior message.

29. The apparatus of any of claims 20 to 28, wherein the source component comprises a client and the destination component comprises a server.

30. The apparatus of claim 20, wherein the processor is a processor of a mobile telephone executing the destination component program thread and the source component program thread.

31. The apparatus of claim 20, wherein the processor is a processor of a first computer and the apparatus is part of a system that further comprises a second computer having a processor executing the source component program thread.