Patent Document

FIELD OF THE INVENTION 
   The present invention generally relates to multicasting systems and methods, and particularly relates to cross-subnet multicasting in wide area networks. 
   BACKGROUND OF THE INVENTION 
   The task of multicasting multicast data between subnets of a Wide Area Network (WAN) such as the Internet is often complicated by non-heterogeneity between subnets of the WAN; for purposes herein, a subnet is generally defined as a multicast zone within which any station can multicast data to any other station within the same zone. For example, subnet implementers and/or administrators must incur some expense and/or go to some effort to render a subnet multicast friendly by configuring routers and/or centralized network control to provide multicasting pass-through service. Also, providing multicasting pass-through service in a subnet constitutes a substantial security risk that is incompatible with various security solution protocols often implemented in secure Enterprise networks. Thus, a multicasting server is often able to multicast data on a multicast address inside the particular subnet within which it resides, but is not able to multicast data into an adjacent subnet or distant subnet. In a related fashion, a multicasting receiver is often able to listen at a multicast address for data multicast inside the particular subnet within which it resides, but is not able to receive data multicast from an adjacent or distant subnet. As a result, multicasting is not truly implemented in today&#39;s WANs due to varying network infrastructures between subnets. 
   What is needed is a way to permit a multicasting server residing in a subnet that is not multicasting friendly to multicast data into an adjacent or distant subnet. What is further needed is a way to permit one or more multicasting receivers residing in a subnet that is not multicasting friendly to request and reliably receive multicasting data from a multicasting server residing in an adjacent or distant subnet. The present invention provides a solution that fulfills these needs. 
   SUMMARY OF THE INVENTION 
   In accordance with the present invention, a multicast relay system for use in a wide area network includes an input receptive of multicast data specifying a multicast channel having a multicast address. A proxy election module is adapted to elect a multicasting server proxy disposed within a subnet associated in memory with the multicast channel, wherein the multicasting server proxy is adapted to receive the multicast data and multicast the multicast data on the multicast address within the subnet. A multicast data relay module is adapted to transmit the multicast data to the multicasting server proxy. 
   Further areas of applicability of the present invention will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description and specific examples, while indicating the preferred embodiment of the invention, are intended for purposes of illustration only and are not intended to limit the scope of the invention. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
     The present invention will become more fully understood from the detailed description and the accompanying drawings, wherein: 
       FIG. 1  is a block diagram illustrating an inter-subnet multicasting relay service in accordance with the present invention; 
       FIG. 2  is a block diagram illustrating components of an inter-subnet multicasting relay service in accordance with the present invention; 
       FIG. 3  is a block diagram illustrating an application program interface between a network application layer and a network transport layer in accordance with the present invention; 
       FIG. 4  is a block diagram depicting a multicast receiver implementing an application program interface in accordance with the present invention; 
       FIG. 5  is a block diagram illustrating an inter-subnet multicast relay service server in accordance with the present invention; 
       FIG. 6  is a flow diagram illustrating a server-side multicast relay method in accordance with the present invention; and 
       FIG. 7  is a flow diagram illustrating a receiver-side multicasting server proxy method in accordance with the present invention. 
   

   DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
   The following description of the preferred embodiment(s) is merely exemplary in nature and is in no way intended to limit the invention, its application, or uses. 
   By way of overview the present invention provides a solution that fulfills the aforementioned needs by using multicasting server proxies; in particular, the provided solution targets applications where multicast membership is dynamic, and member subnets are many, thereby making it undesirable (cost, network administration and management) to deploy multicast relaying proxies at every candidate site. The proposed solution advantageously requires no setup of fixed proxy servers that is local to each subnet, and is adaptive in regard to dynamic receiving application membership. 
     FIG. 1  illustrates an inter-subnet multicasting relay service implemented in a WAN  10  in accordance with the present invention. Wan  10  includes various subnets  12 A- 12 E, that are separated by routers  14 A- 14 D that do not provide multicasting pass-through service. It should be readily understood that subnet  12 E may correspond to any communications subnet, and need not necessarily correspond to a subnet as defined with respect to the present invention. Inter-subnet Multicasting Relay Service (IMRS) server  16  is connected to subnet  12 E, as are remote access users  18 . Various multicast sources  20 A- 20 D and multicast receivers  22 A- 22 D are disposed within subnets  12 A- 12 D adjacent to subnet  12 E. In accordance with the present invention, server  16  provides a relay point that essentially relays multicast data from one of multicast sources  20 A- 20 D to one or more of multicast receivers  22 A- 22 D. Server  16  provides this service by receiving a unicast of the multicast data from a multicast source, and by unicasting the multicast data to a multicasting server proxy within each subnet subscribing to the multicasting channel specified by the multicast data, and the multicasting server proxy multicasts the received data on a multicast address within the subnet within which it resides. 
     FIG. 2  illustrates components of an IMRS system wherein a multicasting server  24  residing within subnet  12 A has multicast media content datastore  26  and is adapted by virtue of application program interface  25  to utilize sending multicasting application  27  to multicast data within its own subnet  12 A, and to also unicast multicast data to server  16 . Interface  25  further causes server  24  to register with server  16  via multicast application registration module  34  as a sending multicasting application in sources datastore  35 . Server  24  coordinates with multicasting session management server  28  as known in the art, such that server  28  utilizes multicasting session management module  31  to maintain catalog datastore  29  of available multicasting sessions and assigned multicasting channels. Receiving application hosts  30 A and  30 B residing in subnet  12 B may thus utilize receiving multicasting applications  42 A and  42 B to access catalog datastore  29  and identify an available multicasting session and assigned multicasting channel. Receiving multicasting applications  42 A and  42 B each have application program interfaces  40 A and  40 B, which are adapted to cause applications  42 A and  42 B to register as candidate multicasting server proxies for subnet  12 B with server  16  via multicast application registration module  34 . Thus, server  16  may elect one of applications  42 A and  42 B as the multicasting server proxy for subnet  12 B via subnet multicasting proxy election module  36 , and relay multicast data received from server  24  to the elected application. Each of interfaces  40 A and  40 B further enable applications  42 A and  42 B to simultaneously listen for multicast data at a designated receive queue, and listen at a multicast channel on subnet  12 B for multicast data. Each of interfaces  40 A and  40 B further enable applications  42 A and  42 B to multicast on the multicast address any data received on a designated receive queue, thereby multicasting the data within subnet  12 B. It should be readily understood that server  24  is adapted to unicast the multicast data to server  16  instead of attempting to multicast it to subnet  12 B, and that server  16  may obtain this adaptation through a registration process that provides appropriate software components to supply sending multicasting application  27  to server  24  in accordance with one or more business methods. It should also be readily understood that software components providing receiving multicasting applications having the application program interface in accordance with the present invention may be supplied to hosts by a multicasting service and/or a multicasting relay service in accordance with one or more business methods. 
     FIG. 3  illustrates the application program interface  40  between a network application layer  42  and a network transport layer  44  in accordance with the present invention. Therein, the application program interface  40  is adapted to utilize the Message Queue Service (MQS)  46  of the transport layer  44  providing Transmission Control Protocol (TCP), Internet Protocol (IP), and/or User Datagram Protocol (UDP) functions. Essentially, the IMRS  48  within the larger multicast platform  50  interfaces directly with the MQS  44 , and therefore can operate within the larger environs of a WAN in accordance with established protocols. 
     FIG. 4  illustrates operation of the receiving application host  30  implementing the receiving multicasting application  42  having the application program interface  40 . The application  42  identifies a multicasting channel assigned to a multicasting session, and the channel information may include multicast address  52  and UDP port  53 ; it should be noted that multicasting channel may optionally include the source address wherever it is referred to within the meaning of the present invention. Interface  40  opens a designated send queue  58  and receive queue  60 , and further obtains relevant host information such as the host IP address  62 , and the host subnet address  64 . It still further causes application  42  to register itself as a candidate multicasting ser proxy for the subnet within which it resides by communicating a registration request  66  to the IMRS server (not shown). This request  66  includes the receiving application&#39;s designated receive queue identity  68 , the host IP address  62 , the host subnet address  64 , and the multicast channel  70 , which includes the UDP port number and the multicast address  52  provided by the multicasting session management server (not shown). 
     FIG. 5  illustrates the operation of the IMRS server  16  receiving registration request  66  and source registration request  67  as at request  69 . For example, multicast application registration management module  34  is adapted to place the receiver&#39;s receive queue identity in candidate multicasting server proxy datastore  32  as a proxy send queue in association with the subnet in which it resides, which is identified by host subnet address  64 , and the multicasting channel  70  it wishes to receive. Thus, a multicasting channel datastore  72  relates a plurality of subnets in a subnet datastore  74 A- 74 B to a particular multicasting channel, which in turn relate a plurality of proxy send queues  76 A- 76 D to particular subnets. For example, datastore  32  may correspond to a hash table having multicasting channels at a first level, subnets at a second level, and proxy send queues at a third level. One skilled in the art will recognize that other implementations are possible that may vary the operation of server  16  in one or more ways. For example, the hash table implementation renders it likely that an elected proxy will only receive on its receive queue multicast data which it has requested. Other implementations, such as shared vectors, may result in an elected proxy receiving all multicast data for a subnet, regardless of which multicast channel it wishes to receive. These alternative implementations should be considered within the scope of the present invention. 
   When server  16  receives a transmission from a multicasting server (not shown) registered as a source in datastore  35 , wherein the transmission includes multicasting data  80  specifying the multicast channel  70 , then subnet multicasting proxy election module  36  may access data store  32  based on the multicast channel  70  and retrieve one proxy send queue registered to each subnet registered to the multicasting channel  70 . It should be readily understood that transmission  70  may specify additional multicasting channels which will result in retrieval of additional send proxy send queues for those channels. The multicasting data relay module assembles a unicast transmission  84  of the multicast data  80  for each retrieved proxy send queue identity  82  and routes the transmission  84  to application receive queue  60  ( FIG. 4 ) utilizing the proxy send queue identity  82 . 
   Interface  40  adapts application  42  to listen at designated receive queue  60 , unpack transmission  84 , and multicast the multicast data  80  received on the receive queue  60  on the subnet within which it resides. The multicast data  80  is thus output to the multicast address  52  for the subnet, and all of the receiving applications on the subnet, including application  42 , are adapted to listen at the multicast address  52  and therefore receive the multicast data  80 . It should be readily understood that interface  40  may be alternatively adapted to allow application  42  to stop listening at address  52  when transmission  84  is received on queue  60 , and simply to utilize the data  80  that it also multicasts on address  52 . 
   When application  42  leaves the session, it may be adapted by virtue of interface  40  to issue an end leave (not shown) to relay module  38  ( FIG. 4 ). In turn, relay module  38  may be adapted to throw an exception (not shown) to subnet multicasting proxy election module  36 . In turn, the session module  36  may be adapted to remove the related proxy send queue from datastore  32  and elect a new proxy for the subnet from those available, if any. It should be readily understood that application  42  may alternatively be adapted to leave a session silently, and that connections may be disconnected involuntarily. Thus, module  36  may be alternatively or additionally adapted to detect disconnection via the MQS, and throw an exception resulting in equivalent update procedures. If no candidate proxies for the subnet are then available, then module  36  is adapted to remove the subnet from the multicasting channel. Further, if no subnets remain for the channel, then module  36  is adapted to remove the channel. As a result, either a new proxy send queue identity for the subnet  82 , a channel removal indicator, or a null value are returned to relay module  38 . In response, relay module may be adapted to either continue relaying the multicast data  80  to the newly elected proxy, or to inform the multicasting server that no subscribers to the channel remain as appropriate. The new proxy for the subnet, which has been listening to the multicasting address and the designated receive queue, merely begins multicasting the multicast data as it is received. The result is dynamic provision of multicast server proxies according to application need without requiring permanent establishment of dedicated proxies in various subnets. 
     FIG. 6  illustrates a relay server-side multicast relay method in accordance with the present invention. The relay method assumes that candidate multicasting server proxies are being added by a second process performed in parallel with the relay method. Beginning at  86 , the method includes receiving a multicast transmission specifying a multicast channel from a multicast source at step  88 . This step may include receiving a unicast directly from the source, receiving a multicast or broadcast transmission at a multicast or broadcast address, and/or receiving the transmission through a relay mechanism instead of from the original source. The multicast channel specifies the multicast address and the user datagram port, and the method includes getting the multicast channel information at step  90 . The method further includes determining at  94  whether any receivers are registered to the channel of the multicast transmission received in step  88 . If so, then a registered multicast receiver is selected for each subnet associated with the channel at step  96 , and the multicast data is transmitted to each selected receiver at step  98 . This transmission continues until it is determined at  100  that a selected receiver has left the session. In such case, processing for that subnet proceeds to step  101 , wherein the receiver is unregistered from the subnet. Then, if more receivers are registered to the subnet as at  102 , then processing for the subnet returns to step  96 , and a new receiver is selected and utilized according to steps  98 - 102 . If it is determined that no receiver is registered to the subnet at  102 , then the subnet is removed from the table as being in association with the channel. If at any time no receivers are deemed registered to the channel as at  94 , then the method may further include notifying the multicasting source and/or multicasting session management system for the source of the multicasting transmission. 
     FIG. 7  illustrates a receiver-side multicasting server proxy method in accordance with the present invention. Beginning at  104 , the method includes acquiring a multicast channel from a multicasting session management server or other source of multicast channels at step  106 . The method also includes opening a receive queue designated for receiving a unicast of multicast data from a multicast relay service at step  108 . The method further includes obtaining relevant subnet information, such as host subnet and/or IP address, for transmission to the IMRS server in step  112  to accomplish registration as a multicast receiver for a subnet and multicasting channel. The method still further includes listening at the designated receive queue for the multicast transmission, and, if the connection is not terminated at  116  and the transmission is received at  118 , then the method includes multicasting on the multicasting channel at step  120  any transmission received on the designated receive queue. The method further includes listening at the multicast address of the multicast channel at step  122 , whether or not the transmission is received at the receive queue. It should also be understood that step  122  can alternatively be dependent on whether the transmission is received at  118 , such that the address is not listened at when the transmission is received at the receive queue. However, the method includes substantially simultaneously listening at the receive queue and the designated receive queue whenever multicast data is not received on the receive queue. If the connection is terminated at  116 , then the method ends at  124 , and/or the method includes communicating an end leave notification to the IMRS server. 
   The description of the invention is merely exemplary in nature and, thus, variations that do not depart from the gist of the invention are intended to be within the scope of the invention. For example, the receiving application program interface in accordance with the present invention may be adapted to selectively allow the receiving application to deliver data received from the relay server directly to the application without transmitting the data via multicast for dialup or any other case that covers a single receiver in a subnet. This shortcut mode provides improved efficiency in such cases and also handles cases where multicasting is not feasible, as with dialup. Also, a sending multicasting application may be adapted to perform the basic functions of a relay service, including registering and electing receivers disposed in various subnets, and unicasting the multicast data to the elected proxies. Further, receiving multicasting applications may be adapted to register with a sending multicasting application rather than a third party provider, in which case the sending application may be considered a relay service. Such variations are not to be regarded as a departure from the spirit and scope of the invention.

Technology Category: h