Abstract:
A method for providing inter-application communication between a sending device and one or more receiving devices in a wireless network comprises the steps of: (i) at the sending device, tagging a data item with an identifier unique to an intended communication between the sending device and the one or more receiving devices; (ii) at the sending device, broadcasting the tagged data item in the wireless network; (iii) at a receiving device, receiving the broadcast data item when the receiving device is within a radio-range of the sending device; and (iv) at a receiving device, accepting the data item for processing when the identifier substantially matches an identifier expected by an application associated with the receiving device; wherein the sending device and the receiving device need not be aware of each other&#39;s presence.

Description:
FIELD OF THE INVENTION 
     The present invention relates to the field of inter-application communications and, in particular, to methods and apparatus for enabling inter-application communication for devices that interact using wireless networks. 
     BACKGROUND OF THE INVENTION 
     For the purposes of this disclosure, we define a wireless network as a mobile network, characterized by wireless links, lack of central infrastructure (such as Domain Name Service), and frequent host mobility (resulting in changes in communication. capability between devices). An example of a wireless network is a network that uses radio signals for communication. By its nature, the strength of a radio signal determines the range within which the signal can be received. We define this range as the “radio-range” for a transmitting device. In a radio-based wireless network, two devices are able to communicate with each other, provided they are tuned for communication (use the same frequency), by virtue of being within radio-range of each other. Two devices cease to communicate if either device moves outside the radio-range of the other device. The radio-range for a device is a function of the strength of the radio transmitter on individual devices. The range could vary from tens of feet (in Bluetooth enabled devices) to several hundred feet (in wireless LAN enabled devices) to tens of miles (in a broadcast by radio stations). It is possible to extend the radio-range of a device by installing repeater nodes in the wireless network. Repeater nodes rebroadcast the transmitted signal, thereby increasing the radio-range for a single transmitting device. For the purposes of embodiments of this disclosure, two devices, in a wireless network, can communicate with each other provided they are within radio-range of each other and use the same radio frequency. FIG. 1A shows an example where two devices  102  are within radio-range  104  of each other, and thus can communicate with each other. As the two devices move apart, they cease communication as soon as they move outside each others radio-range. This is illustrated in FIG.  1 B. 
     Conventional inter-application communication paradigms either involve direct communication in which the communicating applications are directly aware of each other, or mediated communication in which the communicating applications use a commonly known and accessible mediator. 
     One flavor of direct communication is where a receiver “pulls” the data from a sender (e.g., Web browsing). Here, a receiver is explicitly aware of the sender and communicates with the sender using a well-known network name or address. Such a receiver “pull” model of direct communication is shown in FIG.  2 . In this paradigm, each application on the receiver  202  that is interested in receiving data from a sender  208 , sends a request message  204  to a particular port at the sender. The request message header identifies the type of the request along with the identity of the data (if any). The application at the sender processes the request and sends the requested data back as part of the reply  206  to the receiver application. The main weakness of this paradigm, when applied to wireless networks, is that each application on the receiver needs to know the location and address of the application at the sender. 
     Another flavor of direct communication is where a receiver first “registers” its intent to receive data items with a sender. Such a receiver “push” model of direct communication is shown in FIGS. 3A and 3B. During the registration phase (FIG.  3 A), a receiver  302  informs the sender  306  about the type of data that it would like to receive (registration step  304 ). As and when the data becomes available, during the reply phase (FIG.  3 B), the sender  306  “pushes” the data (step  308 ) to the receiver (e.g., Marimba channels—http://www.marimba.com; PointCast—http://www.pointcast.com). The main weakness of this approach, when applied to wireless networks, is that both the sender and receiver need to be aware of each other&#39;s location either by means of a network name or network address where they can send-to or receive-from. 
     An alternate means of direct communication proposed in the literature is based on the technique called Broadcast Disks (described in “Broadcast Disks: Data Management for Asymmetric Communication Environments” by S. Acharya, R. Alonso, M. Franklin and S. Zdonik, In Proceedings of ACM SIGMOD Conference, May 1995). This technique augments the memory hierarchy of clients in asymmetric communication environments by broadcasting data from a fixed server to clients with less powerful machines (who could be mobile). Clients interested in seeking data items missing in their local storage retrieve data from the broadcast channel when the data “goes by.” As the technique is intended primarily for information dissemination from a single source, its main weakness is that it does not support fine-grained arbitrary inter-application communication among mobile clients. 
     Mediated communications are used in tuple-based systems (e.g., Linda tuples as described in “Generative Communication in Linda,” David Gelernter, ACM Transactions on Programming Languages and Systems, Vol. 7, No. 1, Jan. 1985, pp. 80-112, and “Distributed Communication via Global Buffer,” David Gelernter and A. J. Bernstein, In Proceedings of the ACM Principles of Distributed Computing Conference, 1982, pp. 10-18; JavaSpaces as described in “JavaSpaces Specification,” http://java.sun.com/ products/javaspaces/specs/is.pdf, Sun Microsystems, Jul., 1998; and TSPaces as described in “TSpaces,” P. Wycoff, S. W. McLaugry, T. J. Lehman, D. A. Ford, The IBM Systems Journal, August 1998), or queue-based systems (e.g., MQSeries as described in “MQSeries,” http://www.software.ibm.com/mqseries, IBM). In these systems, two applications can communicate by depositing and withdrawing tagged data values in a tuplespace or a queue, without being explicitly aware of each other. 
     FIG. 4 shows an example of a queue-based model of mediated communication. The receiver  402  writes the request message to a queue (step  404 ) with the Queue Manager  408 . The sender  414  retrieves the request message from the queue (step  412 ). After processing the request, the sender writes the reply message (step  410 ) to a queue with the Queue Manager. The receiver then reads the reply message from the queue (step  406 ). The realization of a tuplespace or a queue is achieved by a third entity. This entity is independent of the communicating applications. The main weakness of this approach is that it relies on the constant presence of mediator (e.g., Queue Manager). If, for some reason, the mediator node disappears or fails, two applications cannot continue to communicate. The availability and accessibility of a mediating third party is unlikely in wireless networks which form (when devices come within communication range of each other) and dissolve dynamically (when devices move away). 
     SUMMARY OF THE INVENTION 
     This present invention combines the broadcast capabilities of the wireless networks with uniquely tagged data items to achieve ad-hoc inter-application communication without the above burdensome requirements set forth by conventional inter-application communication paradigms. That is, a sender of data items does not need to be aware of the presence of the recipients of the data items. Similarly, the recipient does not need to be aware of the presence of the sender. In this invention, the sender of a data item tags the data item with an identifier that is unique in the context of the intended communication, and then broadcasts the tagged data item in the wireless network. An application that intends to receive the data item, accepts the data item if the attached tag matches the tag expected by the receiving application. Therefore, two (or more) applications communicate simply by being in radio-range (physical proximity) of each other and agreeing on tag values. There are numerous means in which the sender and receiver applications can agree on the tag values. By way of example only,.tag values for data items can either be preconfigured within the applications, or can be communicated out-of-band to users of the applications. For instance, an application, which displays stock quotes only, can be hardwired to process stock quote tags only. A more customizable application can ask a user to enter data tag values that the application should process. Information about types of available tags can be communicated to the user using out-of-band means such as a user&#39;s manual or advertisement. However, it is to be appreciated that the invention is not limited to any particular tag value agreeing means. 
     It is to be appreciated that the term “application” refers generally to one or more software programs written to perform or provide one or more particular functions. The applications may range from accomplishing simple functions to complex functions. However, the methodologies of the present invention are not limited to any specific application and, in fact, may be applicable to simple communication, of data or some other signal transfer between two devices in a network. 
     Advantageously, in accordance with the present invention, communicating applications no longer need to be directly aware of each other&#39;s presence, for example, in the form of a predetermined address, nor do they need to use a common mediator. 
     These and other objects, features and advantages of the present invention will become apparent from the following detailed description of illustrative embodiments thereof, which is to be read in connection with the accompanying drawings. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIGS. 1A and 1B are diagrams illustrating the concept of radio-range in a wireless network; 
     FIG. 2 is a diagram illustrating a receiver “pull” paradigm of direct communication; 
     FIGS. 3A and 3B are diagrams illustrating a sender “push” paradigm of direct communication; 
     FIG. 4 is a diagram illustrating a mediated model of communication between applications; 
     FIG. 5 is a diagram illustrating an exemplary system environment to which the present invention is applicable; 
     FIG. 6 is a block diagram illustrating an exemplary software architecture of a device in a wireless network employing inter-application communication methodologies of the present invention; 
     FIG. 7 is a diagram illustrating an application programming interface exported by a Data Exchange Service of a device in a wireless network employing inter-application communication methodologies of the present invention; 
     FIG. 8 is a flow diagram illustrating steps performed by an application to send data according to an embodiment of the present invention; and 
     FIG. 9 is a flow diagram illustrating steps performed by a Data Exchange Service to process a broadcast message received by a device and delivered to an application according to an inter-application communication embodiment of the present invention. 
    
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 
     The present invention will be explained below in the context of an illustrative wireless network. However, it is to be understood that the present invention is not limited to any particular wireless network implementation. Rather, the invention is more generally applicable to any network in which it is desirable for applications to communicate without being directly aware of each other, e.g., in the form of a predetermined address, and to communicate without the need to use a common mediator. 
     Referring now to FIG. 5, an exemplary system environment to which the present invention is applicable is shown. The environment comprises computing devices, such as laptop computers  512 , hand held phones and organizers  502 , smart phones  508 , pagers  504  and peripheral devices, such as printers  510 , etc. Each device is capable of communicating with another device using wireless media. To this end, each device is comprised of a wireless transmitter and a wireless receiver. Two devices communicate when they are within radio-range of each other, as illustrated in FIG.  1 A. Communication is established after two devices come within radio-range and establish a network to facilitate communication. The several devices may communicate with each other over a network  506 , as long as they are within radio-range of each other. The network  506  may be any network suitable to permit communication between the devices. The invention is not limited to any particular network implementation. In this embodiment, the primary mode of communication is broadcast, i.e., when a device wants to transmit information, it broadcasts the contents of the information using its wireless transmitter. Any other device that is within the receiving range of the broadcast is capable of receiving this transmission. This implies that the sender is not aware of who the receiver is, and the receiver is not aware of who the sender is. 
     It is to be appreciated that each device shown in FIG. 5 may comprise a processor operatively coupled to memory and I/O devices. It is to be appreciated that the term “processor” as used herein is intended to include any processing device, such as, for example, one that includes a CPU (central processing unit). The term “memory” as used herein is intended to include memory associated with a processor or CPU, such as, for example, RAM, ROM, a fixed memory device (e.g., hard drive), a removable memory device (e.g., diskette), flash memory, etc. In addition, the term “input/output devices” or “I/O devices” as used herein is intended to include, for example, one or more input devices, e.g., keyboard, microphone, etc., for inputting data to the processing unit, and/or one or more output devices, e.g., CRT display, a speaker, etc., for presenting results associated with the processing unit. It is also to be understood that “processor” may refer to more than one processing device and that various elements associated with a processing device may be shared by other processing devices. Accordingly, software components or modules including instructions or code for performing the methodologies of the invention, as described herein, may be stored in one or more of the associated memory devices (e.g., ROM, fixed or removable memory) and, when ready to be utilized, loaded in part or in whole (e.g., into RAM) and executed by a CPU. 
     Referring now to FIG. 6, an exemplary software stack associated with each device in the wireless network is shown. Each device is equipped with a wireless transmitter  608  and a receiver  610 . The transmitter  608  sends out radio signals on a specific frequency used by the network while the receiver  610  listens to a specific frequency to receive data from other devices (we assume that the two devices would use the same frequency hopping scheme to maintain communication). The transmitter and the receiver are used by the communication module  606  for sending and receiving data. The communication module  606  provides functions to a software module called the Data Exchange Service (DES)  604  for sending and receiving messages using the transmitter and receiver. The DES module resides above the communication layer. The DES module provides an application programming interface (API) to the applications for sending and receiving data using the mechanisms described herein. The APIs are shown in FIG.  7 . The applications written for the device ( 602 ), use the DES APIs for communicating with other applications executing on other devices. 
     The present invention introduces the concept of using a Globally Unique Data Identifier (GUDI) in. the context of inter-application communication. A GUDI is a 128-bit globally unique identifier, as described in Microsoft Visual C++ Software Development Kit (available from Microsoft Corporation, Redmond, Wash.). For example, 12345678-1234-1234-123456789ABC is a syntactically correct GUDI. A GUDI is generated using a combination of current date and time, current clock sequence, a forcibly incremented counter value, and a machine (device) identifier. A GUDI represents a particular class of data values or a single data value. In accordance with the invention, it is used to tag all data items that are exchanged during inter-application communication. 
     FIG. 7 shows the programming interface that the DES module exports to the applications. Before using the DES module, the application initializes the module using the DESInitialize( ) function  704 . Each application can choose to either receive communications from other applications asynchronously or synchronously. To receive asynchronous communications from other applications, an application uses the DESRegister( ) function  706 . The function takes as argument a list of GUDIs and a pointer to the callback function that the application has implemented. The signature of the callback function  702  is shown in FIG.  7 . To send a data item to other applications, an application uses the DESSend( ) function  708 . The function takes as argument a list of GUDIs and a pointer to the buffer that the application wishes to transmit. The list of GUDIs is used by the DES runtime to tag data items before transmission. An application can also choose to synchronously receive data from other applications using the DESReceive( ) function  710 . The DESReceive function blocks (waits) until a data item that matches the GUDI specified in the function is available. An application decides whether to receive data synchronously or asynchronously. An application can terminate receipt of data in the future by calling the DESTerminate( ) function  712 . Subsequent to the DESTerminate call, no more data items are delivered to the application. 
     Referring now to FIG. 8, a flow diagram is shown of steps performed by an application to employ inter-application communication according to an embodiment of the present invention. At the time of initialization, the application executes the DESInitialize( ) function (step  802 ). In step  804 , the application registers a list of GUDIs that the application is interested in receiving data for. The application also registers a callback function with the DES module in step  806 . The callback function is used by DES to notify the application when a data item with that GUDI is received. In response to the registration process of step  806 , the DES module stores a list of GUDIs and the application callback handle in its internal data structures. An application can send data to other applications using the DESSend( ) function in step  808 . In step  810 , the DES tags data items it wishes to broadcast with GUDIs specified by the application. The tagged data items are then transmitted into the network. The application may then continue with other application logic. 
     Referring now to FIG. 9, a flow diagram is shown illustrating steps performed by a Data Exchange Service to process a GUDI broadcast message received by a device according to an inter-application communication embodiment of the present invention. The DES module waits to receive any broadcast messages in step  902 . Upon receipt of a message, in step  904 , it checks to see if the message is of valid format, i.e., contains a valid GUDI. If the message is not valid then DES resumes waiting for more messages, i.e., returns to step  902 . If the message is of valid format, in step  906 , DES extracts the GUDI and message content from the message. It then examines its internal data structures to identify any applications that are waiting or blocked for this GUDI in step  908 . In step  910 , if no applications are waiting or blocked then the message is dropped. and DES resumes waiting for new broadcast messages, i.e., returns to step  902 . If an application is waiting, the DES module extracts the application callback handle and notifies the application about the message in step  912 . All blocked applications are notified also. Upon successful delivery of the message to all waiting and blocked applications, DES resumes listening for more messages. 
     Although illustrative embodiments of the present invention have been described herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various other changes and modifications may be made by one skilled in the art without departing from the scope or spirit of the invention.