Patent Application
20120265871
1. Field of the Invention
This invention relates to multicast, client/service-attribute resolution. More particularly the invention relates to discovering client applications and server applications having particular attributes and being located on multiple computing systems in an IP multicast group of computing systems.
2. Background of the Invention
When there are multiple computers on a network, and there is no common system administrator with access to all of those computers, the computers must find devices on the network using some discovery process. Classically, a system administrator or a system network can monitor the network and say, for example, the network includes “Bob's Printer” which can be found at “IP address” and the printer supports “name” protocols. However in a wireless network, for example, each user has his own computing system, and there is no common system administrator in the network. The computer must discover “name” devices on the network for itself.
There are currently extensions to the domain name service (DNS) which extensions are multicast domain name service (mDNS). One implementation is “Bonjour” service by Apple Computer Incorporated, which is used with the iTunes application program among others. Another implementation is Avahi service that is an mDNS service for Linux operating systems. The idea of these extensions to the domain name service is to allow computers to send out information about what services they support and to ask for information about what services other computers on the network support.
In using mDNS there are two sides to a conversation: a requester and a responder. A requester asks other mDNS participants whether or not they support a particular service type, encoded as for example a “proto” protocol. A responder on each participant answers queries and would say, for example, I am named “Joe's phone” and I support the “proto” protocol. If more than one participant supports the “proto” protocol, multiple answers may be received by the requester. Typically the requester then decides which of the answers it is interested in and then performs a separate step to resolve the name “Joe's phone” and the protocol “proto” into an IP address and port over which the desired service can be reached. Attributes of the service may also be found during the resolve phase of the conversation and indicate for example characteristics of specific instance of the service.
In peer-to-peer communications, where multiple users wish to interact as in playing a game, for example, mDNS can be used to link all the users into the same game. However, using mDNS to do this is very cumbersome. The computers desiring to participate in the game must all export the fact that they support the protocol used to establish the game and all devices must query for all other devices on the network that support the game establishment protocol. In order to contact each other, the separate step of resolving the returned names must be performed for every participant and any attributes of the individual participants must be resolved. There is a large amount of network and internal state overhead to track and keep consistent the “name” computers, computers that have the “game” protocols, and computers currently playing the game particularly as players enter and leave the game. To use mDNS to support such a game scenario, the network must either handle a large number of queries or it must store a large amount of network state information.
It is with respect to these considerations and others that the present invention has been made.
In accordance with the present invention, proximity-based communications is established between client and service applications mediated by bus daemons. Client applications consume services and service applications provide services. A unique discovery protocol provides a name service in the bus daemon structure to assist the bus daemons in discovering the service applications available at other bus daemons. Bus daemons periodically announce their existence and provide the address and port over which they may be contacted. They also provide attribute information consisting of a description, such as an instance attribute and a well-known name attribute, of the service applications available at the bus daemon. The name service in the bus daemon structure may also respond to queries as to the availability of requested service applications. When client applications require access to a service application, they query their associated bus daemon that, in turn, queries its name service. When other bus daemons are discovered having access to a requested service application, the requesting client application may arrange that the bus daemons exchange information in a manner that allows a location independent connection to be made between the client application and service application.
In accordance with other aspects, the present invention relates to an apparatus for discovering service applications available for communication through daemons in computing systems in a multicast group of computing systems. A daemon module in a computing system in the multicast group responds to discovery requests from its client applications and its service applications by initiating multicasts of attribute information for client applications and service applications. The attribute information for each client application and service application has at least a well-known-name attribute in the attribute information description of each application. A name service module in the computing system associated with the daemon module responds to a discovery request by initiating a discovery operation request. A responder module in the computing system associated with the name service module responds to the discovery operation request by sending a discovery message to the multicast group. The discovery message has attribute information with a given well-known-name of a service application making the discovery request at the computing system. Also, responder module responds to a first type discovery message from a computing system in the multicast group, the first type discovery message asking for any instance of a named service application with a well-known-name attribute matching one specified by a client application making a discovery request. If the computing system has such an instance of the named service application, the responder module sends a second type discovery message identifying the instance of the named service application with the well-known-name attribute at the computing system. Also, the responder module responds to a second type discovery message from a computing system in the multicast group. The second type discovery message announces an instance attribute and a well-known-name attribute for a service application at the computing system in the multicast group. The responder module notifies the daemon module of the availability of an instance of the service application with the well-known-name attribute at the computing system in the multicast group.
In accordance with still other aspects, the present invention relates to a method for discovering service applications available for communication through a home bus daemon in the user's computing system or through the home bus daemon and a remote bus daemon in a remote computing system of a multicast group of computing systems. In response to a request from a service application available at the home bus daemon, an initiating operation initiates an advertise operation request from the home bus daemon. In response to an advertise operation request, an advertise message is multicast to the multicast group of computing systems. The advertise message has attribute information with an instance identifier and a well-known-name attribute of the service application at the user's computing system and an address of the home bus daemon through which the service application is available. In response to an advertise message from a remote bus daemon, the home bus daemon is notified of the availability of an instance of a service application with the well-known-name attribute at the remote bus daemon.
In response to a discovery request from a client application at the user's computing system, an initiating operation initiates a find-name operation request from the home bus daemon. In response to a find-name operation request, a query message is multicast to the multicast group of computing systems from the home bus daemon, the query message asks for any service application having a well-known-name attribute that matches the name prefix attribute provided in the query message. In response to a query message, a detecting operation detects whether the home bus daemon has the service application that matches the well-known-name prefix attribute in the query message. The detecting operation sends an advertise message if an instance of the service application with the matching well-known-name attribute is available through the home bus daemon at the user's computing system.
The invention may be implemented as a computer process, a computing system or as an article of manufacture such as a computer program product or computer readable media. The computer program product may be a computer storage media readable by a computer system and encoding a computer program of instructions for executing a computer process. The computer program product may also be a propagated signal on a carrier readable by a computing system and encoding a computer program of instructions for executing a computer process.
Some advantages of the invention are the efficiency and speed with which client applications and service applications wishing to communicate with each other may discover each other. Another advantage of the invention is the ease with which client applications and service applications may enter or leave a group of applications that are communicating with each other.
To advertise the availability of a service application at a computing system, its bus daemon sends an advertise request to the name service. In response, the name service sends a UDP message to the multicast IP address. This UDP message includes a GUID (globally unique identifier) for the sending computing system's bus daemon, and the bus daemon's address (IPADDRESS,PORT). The UDP message also includes a list of names of service applications available through the bus daemon at the sending computing system including the newly advertised service application. In effect the sending bus daemon announces:
a. “I have <org.example.Well-Known-Name.Instance> service application.”
The “Well-Known-Name” attribute is typically the name of the program implemented by the service and client applications, but it may be an abbreviation, an acronym or any identifier for the program. The “Instance” attribute identifies an instance of the service application with the well-known-name attribute that is running on its computing system. Other instances of the service application with the well-known-name attribute at the same bus daemon or another bus daemon in the multicast group may be advertised at the same time. Each instance must have a unique identifier that might be established by the service application when it becomes active. Some possible examples of unique identifiers for an instance might be a unique number, a time stamp, user ID, player name or number, computer ID, bus daemon GUID, etc.
For example, the user on a smart phone or laptop computer might want to play a multiplayer game with the well-known-name, SeaAdventure. The multiplayer game may be implemented as a service application to allow other instances of the game to communicate with the local instance of the game, but may also act as a client application to allow the local instance of the game to communicate with other remote instances. The local instance will have to advertise the existence of the local service application, but also discover remote instances of game's service application. This is done via two UDP messages sent by the name service to the multicast IP address. The first UDP message, an advertise message, would tell the bus daemon at every other computing system participating in the logical bus by listening at the multicast IP address that bus daemon GUID (global unique identifier) at IPADDRESS,PORT in the multicast group has available SeaAdventure.Player001, i.e. instance Player001 of SeaAdventure, game's service application. Of course the system could send multiple UDP messages, one per instance of a game, social media application, or other type of service application. Alternatively the system could send a list of instances of games, social media, or other type of service applications that the service application's sending bus daemon wishes to advertise.
This advertise UDP message is referred to as an IS-AT message. In
In another multi-player example, a user of laptop computer 102 enters a wireless network where other users of computing systems are already playing SeaAdventure game. The user will start a client application that will ask the bus daemon in the user's computer to locate instances of SeaAdventure game service applications. The bus daemon will ask the name service to discover those instances, and the name service will send out a UDP WHO-HAS message. This UDP WHO-HAS message is a query message asking:
“Who has <org.example.SeaAdventure.*> service application?”
The wild card asterisk(*) for the instance attribute indicates any instance of the service application with the well-known-name attribute, SeaAdventure, is being sought. The bus daemon of any computing system in the multicast group laptop computer 102, tablet computer 104, smart phone 106 and desktop computer 108—that has an instance of the service application for SeaAdventure game, i.e. a user is currently playing the SeaAdventure game, would reply with an IS-AT message. The message contains the GUID (global unique identifier), IPADDRESS,PORT of the replying bus daemon and a string indicating that SeaAdventure game is available there.
For example, if a user on smart phone 106 is playing SeaAdventure game, the name service on smart phone 106 replies with a UDP IS-AT message containing GUID and address of bus daemon of smart phone 106 and the message in effect saying, “I have Instance, Player001 of service application with well-known-name attribute SeaAdventure.” When the name service of laptop computer 102 receives the UDP IS-AT message, it indicates to its bus daemon that it has discovered a remote bus daemon that is advertising the fact that it has an active SeaAdventure game service application. The bus daemon, in turn, notifies its local client application. The client application can then decide to use the remote, advertised service application and ask the local bus daemon to connect to the remote bus daemon. This logical connection of bus daemons causes information to be exchanged between the bus daemons and that information enables remote procedure calls between the client and service applications. In the case where the SeaAdventure game application consists of both client and a service application part, the symmetric case allows bi-directional communication between the game instances.
Keyboard module 210 is one input device available to CPU 202 through bus 208. Another input device is a touch screen in display 211. Display 212 with its touch screen serves as both an output device displaying information to a user and an input device receiving input from the user via the touch screen. Display 212 is connected to CPU 202 over bus 208.
Network control module 214 connects to CPU 202 to perform network control operations to connect the system to a wireless network via WIFI transceiver 216 or to a hardwired network through Ethernet adapter 218. Network control module may be an intelligent module with its own computing system and memory including cache. Alternatively, it may be implemented as firmware or software running on CPU 202. Likewise the keyboard 210, display 212 memory system 206 may all be intelligent subsystems communicating over bus 208. One skilled in the art is well aware of the many variations possible in the design of a computing system performing the logical operations of the various embodiments of the present invention.
Computing system 200, typically includes at least some form of computer-readable media. Computer readable media can be any available media that can be accessed by the computing system 200. By way of example, and not limitation, computer-readable media might comprise computer storage media and communication media.
Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD), magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other optical storage devices, or any other medium that can be used to store the desired information and that can be accessed by the computing system 200.
Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as an optical fiber network, a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Combinations of any of the above should also be included within the scope of computer-readable media. Computer-readable media may also be referred to as computer program product.
Each application program using a logical bus has a client application, a server application or a combination thereof to communicate with its local bus daemon and thereby communicate with other service applications in other computing systems. For example, a SeaAdventure game, application program in computing system 302 has a client application part 314 and service application part 312, while another instance of the SeaAdventure game, application program in computing system 304 has client application part 322 and service application part 324. Once the bus daemons 306 and 308 are joined, the sense of client or service application is unimportant. The client and service distinction is important only in the service discovery phase to indicate what system is requesting and what system is responding. Once the busses are joined, the client and service applications at computing system 302 or 304 can be viewed as a merged client/service application, or in this case a SeaAdventure game, application. Now if either client application 314 or service application 312 wishes to execute a remote procedure call at service application 324 or client application 322, and if bus daemon 306 is joined with bus daemon 308, bus daemon 306 will build a TCP message to pass the remote procedure call to bus daemon 308. Bus daemon 308 in turn passes the procedure call to the desired client or service application 322 or 324. Any return information is processed in an inverse fashion. Likewise if client application 322 or service application 324 in computing system 304 wishes to execute a remote procedure call at client application 314 or service application 312 in computing system 302, bus daemon 308 will build a TCP message to pass the remote procedure call to bus daemon 306. Bus daemon 306 in turn passes the procedure call to service application 312 or client application 314. Return information is processed in an inverse fashion.
If bus daemons 306 and 308 have not joined when the mobile computing systems come with wireless range of each other, and an instance of the SeaAdventure game, service application 312 is running at computing system 302 with the bus daemon 306, the name service 307 periodically advertises the availability of the instance of SeaAdventure game, service application by multicasting a UDP Advertise message effectively announcing, “I have an instance of a service application with well-known-name attribute, SeaAdventure.” The UDP message with the GUID, IP ADDRESS, PORT for bus daemon 306 along with the well-known-name attribute and instance attribute of the service application 312 is multicast to all bus daemons of the computing systems within range of access point 310 at a local wireless network in a coffee shop, for example. The UDP message from name service 307 is received by all name services within range of the access point 310 that are monitoring the multicast address. Particularly, name service module 309 now knows that service application 312 for SeaAdventure game is available through bus daemon 306 in computing system 302.
Likewise, if a an instance of SeaAdventure game, service application 324 is running at computing system 304 with the bus daemon 308, the name service 309 periodically advertises the availability of SeaAdventure game, service application by multicasting a UDP message effectively saying, “I have an instance of a service application with well-known-name attribute, SeaAdventure.” The UDP message with the GUID, IP ADDRESS, PORT for bus daemon 308 along with the well-known-name attribute and instance attribute of the service application 324 is multicast to all bus daemons of the mobile computing systems within range of access point 310. The UDP message from name service 309 is received by all name services within range of the access point 310 that are monitoring the multicast IP address. Name service module 307 now knows that service application 324 for SeaAdventure game is available through bus daemon 308 in computing system 304. Either client application (314 or 322) may ask their respective bus daemons to connect to the other in which case the bus daemons are joined into a logical bus.
The client and server application nomenclature is symmetrical. Both client and server application parts of an application such as SeaAdventure game in this example are part of the same program running on different computing systems. Once the discovery phase is complete, and the bus daemons are joined, the client and server applications in a steady-state phase of operation are linked to each other and their remote procedure calls and replies flow through the bus daemons between the separate computing systems.
In
Bus daemon 416 receives the IS-AT message from the name service component of bus daemon 406. The Well-Known-Name is entered in the cache of names and bus daemon addresses at bus daemon 416. The availability of service application 402 is communicated to client application 418 via FOUND-NAME message instance 424. The discovery phase is completed. If client application 418 chooses to ask the daemons to connect, service application 402 and client application 418 will be able to send remote procedure calls and procedure results using TCP messages. Bus daemon 406 will continue to periodically multicast IS-AT messages according to the KEEP ALIVE interval with renewed timer counts to advise other bus daemons of the instance of the Well-Known-Name service application 402. The TCP communication between bus daemons may be ended by one of the bus daemons sending a FIN message under control of either the client or service application. If service application 402 should close, this fact is advertised by sending an IS-AT message with a zero timer count. In this way, client applications and service applications may enter or leave participation in a well-known-name program at will without disrupting the operation of the program.
The exemplary conversation between computing systems in a multicast group, as depicted in
The logical operations in the operation flow diagrams of the various embodiments of the present invention are implemented (1) as a sequence of computer implemented acts or program modules running on a computing system and/or (2) as interconnected machine logic circuits or circuit modules within the computing system. The implementation is a matter of choice dependent on the performance requirements of the computing system implementing the invention. Accordingly, the logical operations making up the embodiments of the present invention described herein are referred to variously as operations, structural devices, acts or modules. It will be recognized by one skilled in the art that these operations, structural devices, acts and modules may be implemented in software, in firmware, in special purpose digital logic, and any combination thereof without deviating from the spirit and scope of the present invention as recited within the claims attached hereto.
In
In
When the event is an operation request event, operation-type detect module 706 tests whether the operation request is a FIND-NAME operation request or an ADVERTISE operation request. If it is an ADVERTISE operation request, the operation flow branches from the operation-type detect module 706 to the IS-AT operation 712. IS-AT operation 712 formats and sends a discovery message, in this case an IS-AT message, e.g. message 408 (
If the operation request is a FIND-NAME operation request, the operation flow branches from the operation-type detect module 706 to the WHO-HAS operation 714. WHO-HAS operation 714 formats and sends a discovery message, in this case a WHO-HAS message, e.g. message instance 420 (
When the event is receipt of a UDP Packet from a remote bus daemon, message-type detect module 708 tests whether the UDP packet is an IS-AT message or a WHO-HAS message. If the UDP packet is an IS-AT message, the operation flow branches from the message-type detect module 708 to notify-daemon operation 716. Notify operation 716 notifies the bus daemon associated. with responder that an IS-AT message for <org.example.Well-Known-Name.Instance> service application has been received, and the service application is available through a bus daemon at IPADDRESS,PORT in a remote computing system.
The IS-AT UDP packet is generated at a remote computing system as a result of either an ADVERTISE operation request at a remote bus daemon or as a result of WHO-HAS UDP packet being received at the name service of the remote bus daemon. In either case the receipt of an IS-AT message by a name service at a home bus daemon in the user's computing system is handled by the responder's notify-daemon operation 716. Notify operation 716 notifies the home bus daemon an instance of a service application with a well-known-name attribute is available for interested client applications (if any) attached to the home bus daemon. The operational flow of the bus daemon in response to the notification is shown in
If the UDP packet from a remote bus daemon is a WHO-HAS message the operational flow branches from message-type detect module 708 to “have-name” test operation 718. If the bus daemon does not have an instance of a service application with a well-known-name attribute as asked for in the WHO-HAS message, the operation flow branches NO from the have-name test operation 718 and returns to wait operation 702 to wait for the next event. If the bus daemon has an instance of a service application with the well-known-name attribute sought by the WHO-HAS message, the operation flow branches YES to IS-AT operation 712. IS-AT operation 712 formats and sends an IS-AT message saying the home bus daemon has an instance of the well-known-named service application. IS-AT message instance 422 (
When the event is a timer event, timer-expired detect module 710 detects whether the expired timer event was a retry timer or a keep-alive timer. If the timer event is a keep-alive timer event, the operation flow branches from timer-expired detect module 710 to keep-alive operation 720. Keep-alive operation formats and sends an IS-AT message, e.g. message instances 414, 426 and 427, for all advertised names of service applications currently being advertised by a name service for a bus daemon. Even if a bus daemon sending the IS-AT message has joined with another bus daemon as a result of an earlier discovery process, the keep-alive operation will continue to provide an opportunity for other bus daemons in the IP multicast group to join with the bus daemon. From keep-alive operation 720 the operation flow returns to wait operation 702.
If the timer event is a retry timer event, the operation flow branches from timer-expired detect module 710 to retry operation 722. Retry operation 722 resends a WHO-HAS message, e.g. messages instances 428 and 429, seeking an instance of a well-known-named service applications currently being sought by a name service for a bus daemon with a client application seeking the named service applications. Even if the bus daemon retrying the WHO-HAS message has joined, with another bus daemon as a result of an earlier discovery process, the retry operation will continue to provide an opportunity for other bus daemons in the multicast group to join with the bus daemon by retrying the WHO-HAS message. From retry operation 722. the operation flow returns to wait operation 702.
Although the invention has been described in language specific to computer structural features, methodological acts and computer processes on computer readable media, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific structures, acts or media described. As an example, other logical operations may be included in the bus daemon discovery process. Also to the extent
The various embodiments described above are provided by way of illustration only and should not be construed to limit the invention. Those skilled in the art will readily recognize various modifications and changes that may be made to the present invention without following the example embodiments and applications illustrated and described herein, and without departing from the spirit and scope of the present invention, which is set forth in the following claims.
