KR101278861B1 - Applicaton-level multicasting architecture - Google Patents

Abstract

An application-level multicasting architecture is provided that allows multiple nodes to interact in real time with data packets being routed based on information about connection status between nodes. Each node shares their connection state with other nodes in the same interactive session. Data packets can be routed at the application level using multiple packet transfer protocols available on the transmitting node. The particular transport protocol may be selected based on the quality of service (QoS) requirements of the data packet. Nodes in the interactive session can relay data packets to other nodes according to a routing map generated based on the connection state. An application-level multicasting architecture can be implemented for any multi-party interactive application, such as video conferencing, multiplayer games, distance learning, virtual meetings, and applications for voice communication.

Multicasting, Connection Status, QoS, Interactive Sessions, Routing Maps

Description

System in which multiple nodes participate in an interactive session and its associated device-readable medium {APPLICATON-LEVEL MULTICASTING ARCHITECTURE}

With the development of Internet technologies and broadband networks, the number of multi-party interactive applications available on the market is increasing. Multi-party interactive applications generally allow multiple parties to interact in real time. Examples of these applications are video conferencing, internet gaming, distance learning, and the like. Media transfers in these applications feature one-to-many semantics.

Multi-party interactive applications utilize a communication mechanism at the network layer to manage the transmission of packets between applications. In general, only one type of transport protocol is used. For example, a multi-party interactive application can send packets to other applications using the Transmission Control Protocol (TCP) mechanism. TCP is a reliable protocol for controlled message delivery and requires a separate connection for each source-destination pair. Thus, using only the TCP mechanism entirely can interfere with interactive sessions involving multiple participants.

The use of user datagram protocol (UDP) may be a faster way for a multi-party interactive application to send packets to other applications. However, UDP is connectionless and provides little error recovery service. Thus, UDP is not a desirable transmission mechanism when reliability is an important requirement.

Multi-party interactive applications can also use IP multicast to handle data transmission. IP multicast is a way that messages can be sent simultaneously to a series of destinations. Unfortunately, IP multicast generally requires specialized routers that understand the protocol and can replicate packets in a timely manner. Thus, although IP multicast can be effective in private networks, IP multicast is not useful for real-time interaction of nodes on completely different networks over the Internet.

The following provides a simplified summary of the subject matter in order to provide a basic understanding for the reader. This summary is not an exhaustive overview of the subject matter, and does not identify or delineate the major / critical components of the present invention. Its sole purpose is to present some concepts described herein in a simplified form as a prelude to the more detailed description that is presented later.

Embodiments of the present invention provide an application-level multicasting architecture that allows multiple nodes to interact in real time with routed data packets based on information about connection states between nodes. In one implementation, each node shares their connection state with other nodes in the same interactive session. Data packets can be routed at the application level using multiple packet transfer protocols available on the transmitting node. The particular transport protocol may be selected based on the quality of service (QoS) requirements of the data packet. Nodes in the interactive session can relay data packets to other nodes according to a routing map generated based on the connection state. This multicasting architecture can be implemented for any multi-party interactive application, such as applications for video conferencing, multiplayer games, distance learning, virtual meetings, and voice communication.

Many of the incidental features will be better understood with reference to the following detailed description considered in connection with the accompanying drawings.

1 illustrates an example application-level multicasting (ALM) system 100.

FIG. 2 shows an exemplary architecture for the ALM module shown in FIG. 1.

3 illustrates an example routing map for an application-level multicasting system.

4 illustrates an example protocol layering model for an application-level multicasting system.

5 illustrates an example header for a connection-level protocol data packet for an application-level multicasting system.

6 illustrates an example header for a routing-level protocol data packet for an application-level multicasting system.

7 illustrates an example data packet with routing-level protocol link state information for an application-level multicasting system.

8 illustrates an example data packet with bandwidth measurement information for an application-level multicasting system.

9 illustrates an example data packet with bandwidth measurement reports for an application-level multicasting system.

10 illustrates an example process for communicating with nodes of an interactive session in an application-level multicasting system.

FIG. 11 illustrates an example process for monitoring a connection state with nodes associated with an interactive session. FIG.

12 illustrates an example process for processing a data packet associated with an interactive session.

13 illustrates an example computer device that implements the described systems and methods.

The description will be better understood upon reading the following detailed description based on the accompanying drawings.

Like reference numerals in the accompanying drawings are used to indicate like parts.

DETAILED DESCRIPTION The detailed description provided below with reference to the accompanying drawings is intended to describe embodiments of the present invention and is not intended to represent the only form in which embodiments of the present invention can be constructed or used. This description describes the functions of these embodiments and a sequence of steps for configuring and operating these embodiments. However, the same or equivalent functions and sequences may be achieved by other embodiments.

1 illustrates an example application-level multicasting (ALM) system 100. Multicasting is the process of delivering a common message to a selected group of recipients. Unlike IP multicasting, where a network router must determine the packet forwarding path and replicate packets if necessary, application-level multicasting leaves all functions to the end system. ALM does not require any special support from network routers and can therefore be easily adapted on top of existing network infrastructure. As shown in FIG. 1, system 100 includes a multi-party interactive application 113-115 in devices 103-105. The multi-party interactive application is configured to allow members of the interactive session to interact with each other via multicasting in the network 135. In this example, the multi-party interactive application 113-115 can be any type of application that can interact in real time, such as video conferencing, multiplayer games, distance learning, virtual conferencing, voice communication, and the like. The interactive session includes all sessions that allow the multi-party interactive applications 113-115 to exchange data. For example, an interactive session may be a video conference, voice conference, multimedia conference, online game, or any event involving multiple users. Session controller 131 in server 130 is configured to establish a communication session between multi-party interactive applications 113-115.

For the actual communication process, the multi-party interactive application 113-115 is configured to interact with the ALM modules 123-125 in the device 103-105. The ALM modules 123-125 are configured to handle communication between the multi-party interactive applications 113-115 with application-level network monitoring and data packet routing. In particular, the ALM modules 123-125 are configured to determine the available transport mechanisms and to transmit data packets with the most appropriate mechanism available. The ALM modules 123-125 are also configured to monitor the connection states between the devices 103-105 and route data packets according to the most updated state. An example ALM module is described below with respect to FIG. 2.

In an example operation, the multi-party interactive application 113 receives a request from a user to initiate an interactive session with other users at the devices 104-105. The multi-party interactive application 113 establishes a session with the session controller 131, and the session controller 131 sends information about this session to other members in order to join the initiating user to the session. To the multi-party interactive application 114-115. The multi-party interactive applications 113-115 then interact with the ALM modules 123-125 to establish a connection (ie, a link) between each other. The ALM modules 123-125 then determine the connection status to each other, such as latency, connectivity, available transport protocols, and so forth, and send this information to each other. Based on this information, each ALM module calculates a path for sending data packets to each of the remaining devices in the interactive session.

FIG. 2 shows an exemplary architecture for the ALM module 123 shown in FIG. 1. The ALM module 123 allows a node (eg, a device running a multi-party interactive application) to communicate with other nodes in an interactive session with multiple members. In particular, a multi-party interactive application may rely on the ALM module 123 to actively manage data packet routing instead of relying directly on one-to-one connections. The ALM module 123 may select from a number of types of protocols to handle data packet routing. These protocols generally include Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and protocols related to IP multicast. UDP is a light-weight protocol suitable for media stream transmission. TCP is a reliable protocol suitable for control message delivery. End systems in the same interactive session may be configured to establish both TCP and UDP channels between each other. This connection attempt is made by a private address that the client sees locally, a public address found by the server, or a public address that the client retrieves from Universal Plug and Play (UPnP) -capable network address translation (NAT). It can be sent to various types of network addresses such as addresses, IP multicast addresses, and so on.

In order to enable UDP communication between end systems behind different NATs, a UDP punching protocol is defined, similar to the Simple Traversal of UDP through NAT (STUN). In one example implementation, each node sends some number of UDP packets (eg, 10 packets) to each available network address of the remaining nodes in the interactive session. If a transmitting node cannot receive a response after sending all of these packets to a particular node, the transmitting node assumes that that particular node cannot be reached via UDP.

In addition to TCP and UDP, ALM module 123 uses IP multicast when available. IP multicast is an efficient mechanism for one-to-many data distribution. However, IP multicast is generally not installed worldwide due to inherent problems. In general, IP multicast generally has spotty deployments in private networks. When available, IP multicast can significantly improve the efficiency of data delivery. In an example implementation, each interactive session is associated with an IP multicast address, which may be randomly generated by the node or server that initiated the session. This address can be registered with the session controller on the server and distributed to them when the remaining nodes join. Each node that joins this interactive session sends out its own information. If a node receives a probing packet from a member in the same session over an IP multicast channel, that node may stop TCP / UDP probing and use IP multicast for all subsequent communications.

As shown in FIG. 2, the ALM module 123 includes components at the application level. These components may be implemented in a session layer 202, a member layer 203, and a routing layer 204. The ALM module 123 may also include components at the network level. These components may be included in a connection layer 208 and a transport layer 209.

The ALM module 123 is configured to allow a user to initiate and participate in multiple interactive sessions simultaneously. For example, ALM module 123 may be configured to support a multi-party A / V conferencing application that allows a user to establish multiple conference sessions with different member node sets. The ALM module 123 may also allow a user to attend multiple conference sessions at the same time. In session layer 202, session objects, such as session objects 214 and 215, are configured to maintain an interactive session and a list of members or attendees for each session. Session objects 214 and 215 are managed by session manager 212.

Because the ALM module 123 includes components at different layers, the components at the connection layer 208 may not know which interactive session the member node is participating in. Thus, even when a node is present in more than one session, the ALM module 123 can create only one node connection module instance and maintain only one connection per type.

In the member hierarchy 203, each of the member modules 227-229 is configured to maintain the member's application-level attributes, such as the member ID, the interactive session in which the member is participating, and so forth. In general, there is a one-to-one mapping between member modules 227-229 at the application level and node connection modules 247-249 at the network level. Each of the member modules 227-229 is also configured to manage media data from the corresponding member and to assemble A / V packets when channel coding is used.

The local member module 225 is configured to manage the local stream 223 generated by the multi-party interactive application on the same node. For example, local member module 225 receives a data stream from a media capture module within the node and sends this stream to other nodes in the interactive session using the information provided by member modules 227-229. Can be.

Components in the routing layer 204 function as multicast-supported routers at the application level. In general, outgoing and incoming packets for ALM module 123 pass through routing layer 204. Components at routing level 204 forward the application-defined packets to the remaining members in the interactive session. The destination ID in the packet can be used to select the next hop to forward the packet. As shown in FIG. 2, the components in the routing layer 204 can include a network monitor 234, a routing manager 236, and a socket 238.

The routing manager 236 is configured to handle data packet routing for the ALM module 123. The data packet processed by the ALM 123 may have multiple destinations. For example, the local node may not be the only destination or even the destination of packets received by that node. Thus, for any incoming packet, routing manager 236 is configured to check whether the local node is one of the destinations. In such case, routing manager 236 forwards the packet to the higher layer. The routing manager 236 is also configured to check if this packet should be relayed to other nodes. Routing information may be found in a local routing table maintained by routing manager 236 or may be carried by packet.

The ALM module 123 consists of application-level connection state routing. Each node periodically measures the network status of its neighbors and propagates this information to all other nodes in the same interactive session. Network monitor 234 is configured to probe and propagate network information. Network monitor 234 is also configured to maintain a map of nodes in the same interactive session. Each time a connection status message arrives, network monitor 234 uses this information to update the map.

When the connection state changes, the routing manager 236 recalculates the path for each active stream by any method such as Dijkstra's SPF algorithm, extended broadest path first (BPF) algorithm, and so forth. It is configured to. The routing manager 236 can also recalculate the path to the active stream when the subscription status of the node associated with the active stream changes. Routing information is stored in the routing table. Unlike packet-specific IP routing, ALM 123 consists of source-specific per-stream routing. Data propagation paths are computed at the source and forwarded to all relay nodes. Thus, routing manager 236 maintains a routing table for the local stream as well as the stream to which it should relay.

At the network layer connection layer 208, each node connection 247-249 is configured to maintain an available connection, such as TCP, UDP, and IP multicast to a particular node. Node connections 247-249 provide an abstract network channel for communication with each node associated with the interactive session. The type of connection available is generally transparent beyond the routing layer 204. Outgoing packets generated by local stream 223 or network monitor 234 typically look through the routing table to obtain next hop information. The packets are then forwarded to the corresponding node connection module 247-249. The node connection module 247-249 automatically selects the most appropriate connection for sending packets according to the specified quality of service requirements.

Node connection modules 247-249 are managed by node connection manager 244 that is configured to add, delete, and update module instances. In one implementation, incoming packets generally do not go directly to node connection module 247-249. Instead, incoming packets can be forwarded to node connection manager 244, which is configured to maintain a receive buffer for each TCP socket, because TCP sockets are joined or joined by an underlying network. Because it can be divided. Node connection manager 244 may be configured to maintain an incoming bitstream and do not forward these streams to node connection module 247-249 until a complete packet is received. For UDP packets, node connection manager 244 may be configured to unpack the packet and retrieve the source ID before delivering the packet to the correct node connection module.

At the transport layer 209, the ALM module 123 is configured to use the transport mechanism available at the node. In this example, the transport mechanism at the node includes TCP 253, UDP 254, and IP multicast 255.

The ALM module 123 may expose an application program interface (API) that allows applications such as the multi-party interactive application 113 of FIG. 1 to interact with the ALM module 123. Below are example APIs that may be exposed by the socket 238 of the ALM module 123.

InitSocket () Initializes an application level socket.

CloseSocket () Closes an application level socket.

AddMember (MemberID id, ADDRESS address) Call this interface to inform the routing and connection layers of new member nodes in the interactive session. Without calling this interface, the routing layer may not send any data or receive any data from this member.

UpdateMember (MemberID id, ADDRESS address) Call this interface to update address information of member node.

CloseMember (MemberID, id) Call this interface to inform the routing and connection layers of the member node's leave. After this method is processed, the local site may no longer send data to its members.

CreateStream (StreamType type, StreamInfo info) Call this interface to register a new stream, such as audio or video. StreamInfo contains the bit rate of the stream.

UpdateStream (StreamID id, StreamInfo info) Call this interface to update the StreamInfo of a particular stream.

DeleteStream (StreamID id) Call this interface to unregister an existing stream. The corresponding routing information may be deleted from the routing table.

AddSourceMembership (MemberID id, StreamType type) Call this interface when a user wants to subscribe to a particular stream of a particular member node.

DropSourceMembership (MemberID id, StreamType type) Call this interface to unsubscribe a user from a particular member node to a particular stream.

AddReceiver (StreamType type, MemberID id) Call this interface when the local site receives a subscription message from the member id.

RemoveReceiver (StreamType type, MemberID id) Call this interface when the local site receives an unsubscription message from the member id.

UpdateReceivers (StreamType type, MemberIDSet idSet) Call this interface to update the receiver set of a particular stream.

Send (StreamlD id, LPVOID data, UINT length) Call this interface to send data for a specific stream. The application layer may not need to specify a receiver set because the ALM 123 can be implemented as a per-stream routing protocol. The receiver set of each stream is maintained by the routing layer.

BroadcastMessage (Message msg) Broadcasts a control message to all of the members in an ALM group whether or not they subscribe to any of the local streams.

SetOnReceiveCallback () Calls this interface to set a callback function to receive application level data, such as audio and video, from other conference members.

The following is an example API that may be exposed by the routing manager 236.

GetRoutingTopo (MemberID id, StreamType t, CTopology & tp) This interface allows developers / users to visualize application level transfer paths. The topology may be stored in a block of memory and implemented in the same format as defined in the routing-level protocol.

The following is an example API that may be exposed by the network monitor 234.

SetBWMeasurementData (LPVOID data [], UINT unitLen, UINT packets) This interface allows the developer to set the data used for bandwidth measurements. Data is segmented at the application level and coded (if the developer wishes to do channel coding).

SetBWDataProcessCallback () If the developer wants to use the bandwidth measurement data, the developer can set this callback function by calling this interface.

3 shows an example routing map 300 for an application-level multicast system. This example routing map 300 includes six nodes participating in an interactive session handled by an application-level multicasting system. In general, node 103 builds map 300 based on network information, such as connection status between nodes collected by the network monitor. Exemplary routing map 300 illustrates data packet routing for a stream generated by node 103 or sent to node 103 to relate to child nodes 104-108. As shown in FIG. 3, node 103 is configured to send data packets directly to nodes 104 and 105 via connections 312 and 313, respectively. Connections 312 and 313 may be implemented in any type of protocol. For example, connections 312 and 313 may use TCP, UDP or IP multicast depending on QoS requirements. Data packet routing can be implemented in a variety of ways. For example, routing information such as the routing map 300 or the routing table may be transferred to a relay node such as the node 105. Routing information, including source and destination identifiers and the like, may also be included in the data packet.

In the exemplary routing map 300, node 103 relies on node 105 to forward data packets to nodes 106-108 by connection 314-316. For example, nodes 105-108 may be part of a private network for which IP multicast is available. Thus, node 105 may be configured to transmit data packets by connection 314-316 implementing the IP multicast protocol.

4 illustrates an example protocol layering model 400 for an application-level multicasting system. Exemplary layering model 400 allows an application-level multicasting system to define protocols at the connection layer, routing layer, and application layer. For example, an application-level message with an application-level header 402 and data 412 may be encapsulated in a routing level datagram with data 413. Routing-level messages, including routing level header 403 and data 413, may be encapsulated in a connection-level datagram with data 414. The connection-level message with the header 404 is then sent in a message with the headers 405-406 and data 415-416 using the transport layer protocol.

5 shows an exemplary header 500 of a connection-level protocol data packet for an application-level multicasting system. In general, the connection layer is the lowest layer controlled by the application-level multicasting system. Messages at the connection layer are generally handled by the node connection manager or node connection module corresponding to the node in the interactive session, such as node connection modules 247-249 of FIG.

As shown in FIG. 5, an example connection-level data packet header 500 includes a magic word field, a version field, a reliability field, a message ID field, a message length field, a sender ID field, and It may include an ACK order field. The magic word field identifies the application-level multicasting system. The version field shows the version of the application-level multicasting system. The reliability field indicates whether the current packet is to be transmitted through a reliable transport channel. If this packet requires reliable transmission and is received from a UDP channel, an ACK needs to be sent upon receiving this message. The ACK Order field contains the sequence number of the packet used for acknowledgment of receipt of the ACK-needed packet.

The message ID field contains message type information. In one example, the message type may be defined as follows.

enum CLP_MESSAGE_TYPE

{

CLP_HEL = 0x0001, // Hello

CLP_PRB = 0x0002, // Probe message used to measure RTT

CLP_APR = 0x0004, // Answer to Probe Message

CLP_ACK = 0x0008, // acknowledgment for ack_required packet

CLP_OTH = 0x0010, // other

}

The message length field shows the length of a packet including the connection layer header 500. The sender ID field contains a member ID of a packet sender, which may be an ID different from the packet source.

In one example implementation, the Magic Word field is 6 bits, the Version field is 2 bits, the Reliability field is 1 bit, the ACK Order field is 8 bits, the Message ID field is 16 bits, and the Message Length field is 16 bits. Bit, and the sender ID field is 128 bits.

As described above, the message type may include a Hello message CLP_HEL, a probe message CLP_PRB, an answer probe message CLP_APR, and an acknowledgment message CLP_ACK. Hello messages are often used to establish a connection. When a node accepts a TCP connection request, the first message it receives from this connection is usually a Hello message. Otherwise, the host node can close this connection. The host node can also use the Hello message to ping other nodes in an interactive session over UDP and IP multicast channels. Upon receiving the Hello message, the node connection manager may check whether a node connection module already associated with the sender ID in the header of the data packet already exists. In that case, the node connection manager updates the connectivity information for the node connection module (eg, sets the UDP channel state to "available" if a Hello message is received from UDP). Otherwise, the node connection manager creates a new node connection module instance and associates it with the sender ID in the packet header. The body of the Hello message is empty because the sender ID that is always the same as the source ID in the Hello message has already been passed in the connection-level protocol packet header.

The Hello message can also be used as a keep-alive message. For example, the host node may send a Hello message to all available UDP and IP multicast channels every 5 seconds to keep the link alive. If the host node has not received a Hello message for some time (eg, for 30 seconds) from a particular link, the host node may assume that the connection is disconnected. In this case, the node connection module instance attempts to reconnect.

Probe and Answer Probe messages may be used to measure end-to-end latency. Both of these messages may have a DWORD field that contains the same body structure, that is, a timestamp. In one example implementation, the host node of the interactive session sends a probe message every 10 seconds on all available UDP channels. The time stamp in the packet indicates the transmission time. Upon receiving this message, the member node in the interactive session changes the message ID to Answer Probe and immediately returns the packet. When the host node receives the return packet, the host node can calculate the RTT by subtracting the timestamp delivered in the packet from the current time. This result is reported to Network Monitor.

In application-level multicasting systems, there are basically two kinds of packets: control messages and media streams. Loss of media data affects communication quality, while loss of control messages is usually disruptive. For example, the loss of a subscription request may cause the subscriber to wait, and the loss of network status updates may result in network congestion. Thus, a reliable TCP channel is usually preferred for sending control messages.

However, with the presence of firewalls and NATs, TCP connections are not always available. Sometimes, UDP is the only channel available for two end systems to communicate. In one example implementation, an application-level multicasting system may use a lightweight mechanism similar to the “timeout and retransmission” approach in TCP to ensure reliable delivery over UDP. The reliability field in the connection-level protocol packet header may be used. An indication in this field (eg, 1 in the 1 bit reliability field) indicates that the data packet requires an acknowledgment. Sliding window mechanisms may not be preferred because there may not be a need to ensure in sequence delivery.

The CLP_ACK message is used to acknowledge receipt of an ack-needed packet. For example, the body of the packet may include a sequence number indicating which packet the member node received. Small fields (eg 8-bits) can be used for the sequence number because the amount of ack-field packets will not be high.

The CLP_OTH message can be used to indicate that the packet belongs to a higher layer. In such a case, components at the connection level may detach the connection-level protocol header and pass the data to the routing level protocol.

6 shows an exemplary header 600 of a routing-level protocol data packet for an application-level multicasting system. As shown in FIG. 6, an exemplary routing-level data packet header 600 includes a source ID field, a message type field, a media type field, a number of receiver field, a topology length field, a receiver. It may include a list list field, a sequence number field, a bit rate field, and a topology field. The source ID field includes a member ID of a packet source. The message type field contains message type information. In one example, this message type may be defined as follows.

enum RLP_MESSAGE_TYPE

{

RLP_LKST = OxOl, // link status information

RLP_SBSC = 0x02, // Join Request

RLP_UNSB = 0x04, // Unsubscribe Request

RLP_ACTP = 0x08, // Accept Topology

RLP_RJTP = 0x10, // Deny Topology

RLP_BWMS = 0x20, // Bandwidth Measurement

RLP_BWRP = 0x21, // Report Bandwidth Measurement

RLP_STRM = 0x40, // media stream

RLP_APPM = 0x80; // application-level messages

RLP_QUIT = OxFF, // End Session

}

The media type field indicates the type of media data included in the data packet. The number of recipients field indicates the number of recipients of this packet. The topology length field indicates the number of entries in the topology field. The recipient list field contains an entry, and each entry in the list contains a member ID. The sequence number field contains the sequence number of the topology. The stream bit rate field contains the new bit rate of the stream associated with the topology. The topology field contains the topology of the multicast tree. This field may be included in a message of type RLP_STRM, which may include routing information of the stream.

In one example implementation, the message type field includes 8 bits, the source ID field includes 128 bits, the media type field includes 7 bits, the receiver number field includes 8 bits, and the topology length field is Includes 8 bits, each entry in the recipient list field includes 128 bits, an order number field contains 32 bits, a stream bit rate field contains 32 bits, and each entry in the topology field is 128 bits It contains a member ID and a 32-bit child number.

7 illustrates an example data packet 700 with routing-level protocol link state information for an application-level multicasting system. In general, routing-level protocol link state data packets are sent by a node's network monitor to monitor a link or link with other nodes associated with an interactive session. The network monitor collects network status and periodically propagates this information to other member nodes in routing-level protocol link status data packets. As shown in FIG. 7, an exemplary routing-level link state data packet 700 may include a number of links field, a destination ID field, an RTT field, an available bandwidth field, and a more links field. It may include.

The link number field indicates the number of link state entries in this packet. Each link state entry includes the destination ID, the RTT and the available bandwidth of the link. A node typically posts the link state of links starting from that node. Each destination ID field entry may contain only the member ID of the end node. The RTT field and the bandwidth field each contain information about a round trip time (RTT) and a transmission bandwidth of a link. The additional link field may contain information about other available links starting from that node.

In general, routing-level protocol link state data packets are forwarded to the network monitor. The media delivery route is recalculated for each stream based on the new information. If these paths differ from previous calculations, the new topology can be carried in all outgoing data packets of this media type until this topology is accepted by all of the inner nodes in the new multicast tree.

A user of a multi-party interactive application in an application-level multicasting system may choose to subscribe / unsubscribe to a particular media stream of a particular member in an interactive session. A subscribe / unsubscribe message can be used for this selection. These messages may include the media type. The subscriber ID and media provider ID corresponding to the source ID and receiver ID may be retrieved from the routing-level protocol data packet header. These messages are typically delivered to components at the routing level. Network dynamics and subscription status may be entered into the routing manager. If there is a change in either input, you may need to recalculate the multicast tree.

Upon receiving topology information from the source node associated with the interactive session, for example, according to the most recent available bandwidth measurement, the receiving node can check whether the receiving node can relay the stream as required. . In such case, the receiving node updates the routing table and sends an RLP_ACTP message to the source node. Otherwise, the receiving node leaves the routing table and sends an RLP_RJTP message to the source node.

The RLP_ACTP message may include the sequence number of the topology. This sequence number is generated by the source node and passed to the topology section of the packet. This sequence number helps the source node verify that its acceptance is for the most recent topology. The source node stops transmitting the topology after receiving RLP_ACTP from all internal nodes in the multicast tree.

Sometimes, especially when two or more source nodes change their topology at a similar time, multiple source nodes may tell the same receiving node to relay their data. Because the available bandwidth is first used in first-come-first-served (FCFS) fashion, any late arrival relay request may not be fulfilled. In this case, the relay node sends an RLP_RJTP message to the source node. In addition to the sequence number of the rejected topology, the packet may contain the latest link state information of the receiving node. Based on this new information, the source node can recalculate its multicast tree and deploy a new topology with a new sequence number.

8 shows an example data packet 800 with bandwidth measurement information for an application-level multicasting system. Packet 800 is generally used by a network monitor to measure data communication performance. The round number field indicates which round of measurement the packet belongs to. The rounding number field serves to prevent the packets from successive measurement processes from intermingling. The sequence number field contains the in-sequence number of this packet. The timestamp field records the transmission time. The data field contains data associated with bandwidth measurement information.

Application-level multicasting systems allow users to set up and process bandwidth measurement data at the application layer. Examples of application layer allocation data are the most recent I-frames of a user's display image and real-time video. These data can be passed to the network monitor through the exposed interface. By default, network monitors can use block of nonsense data to measure bandwidth. Developers can also set up callback functions to process measurement data. The structure of the data portion can be defined by the developer.

9 shows an example data packet 900 with bandwidth measurement reports for an application-level multicasting system. Packet 900 is generally forwarded by the node's network monitor to other nodes associated with the interactive session. The round number field identifies the specific round of measurement. The increasing trend field indicates whether the increasing trend of one-way delay is observed in a particular round of measurement. If no tendency to increase is observed in the current round, the sender may increase the probing rate in the next round. The Available Bandwidth field records the calculated available bandwidth of the measured path.

Nodes in an application-level multicasting system may send different data packets to other nodes in the same interactive session. For example, prior to leaving the interactive session, the node may send an RLP_QUIT message to all nodes of the session via any of the available channels. Upon receiving this message, each node in the application-level multicasting system can clear the corresponding entry in the routing table and scan the multicast tree if the leaving node is a subscriber to its stream. Can be recalculated.

The media stream data processed by the application-level multicasting system may be audio, video or any user-defined stream. Upon receiving the RLP_STREAM packet, components at the routing level, such as the routing manager, can check whether the packet contains topology information. Then, from the local subscription list, the routing manager can check whether the local user is subscribed to the stream associated with the packet. In such a case, the routing manager may separate the routing-level protocol headers and pass the data of the routing-level protocol packets to the application-level protocol component. The routing manager can search the routing table to see if this packet should be forwarded to other nodes in the interactive session. If it is necessary to forward, the routing manager packs the routing-level protocol header and forwards this packet to the underlying link layer.

An application-level component of an application-level multicasting system may define its own message that lower layers may not understand. When receiving such a message, the routing layer passes it directly to the application level. Application-level components are configured to process media streams, including any user-defined streams. Developers can define application-level headers as needed. If channel coding is used, fragmentation and reembling are handled at the application level.

 10 illustrates an example process 1000 for communicating with nodes of an interactive session in an application-level multicasting system. The example process 1000 can be implemented by a node to initiate and configure an interactive session. At block 1002, a request for an interactive session is sent to the session controller. At block 1004, information about nodes associated with an interactive session is received. At block 1006, a connection is established with each of the nodes. At block 1008, connection state information is received from each of the nodes. At block 1010, a routing map for sending data packets to each of the nodes is calculated. At block 1012, the calculated routing map is provided to the nodes. At block 1014, the content is transmitted using its routes. At block 1016, the connection status for each node is monitored. An example process for monitoring connection states is described in connection with FIG. 11.

11 illustrates an example process 1100 for monitoring a connection state with nodes associated with an interactive session. At block 1102, a data packet is identified. At decision block 1104, a determination is made whether the data packet includes state information for the node. If yes, process 1100 goes to decision block 1106. If the data packet does not include link state information, process 1100 goes to block 1114 where the data packet is processed. An example process of processing data packets will be described with respect to FIG.

 At decision block 1106, it is determined whether the connection state has changed. If not changed, the process returns to block 1102. If the connection state has changed, process 1100 continues at block 1108 where the routing map is recalculated according to the changed connection state. At block 1110, the recalculated path is provided to the node.

12 illustrates an example process 1200 for processing a data packet associated with an interactive session. The data packet may be sent by any of the nodes associated with the interactive session. At block 1202, a data packet associated with an interactive session is received. At decision block 1204, it is determined whether the packet is associated with a local destination. If so, process 1200 continues to block 1206 where the packet is forwarded to the multi-party interactive application for processing. This process then goes to decision block 1208. If the packet is not associated with a local destination, process 1200 also goes to decision block 1208.

At decision block 1208, a determination is made whether the data packet should be relayed. If the packet is not relayed, process 1200 returns to block 1202. If the packet is relayed, this process goes to block 1210 where the routing map associated with the interactive session is identified. At block 1212, the packet is forwarded to one or more relay nodes according to the routing information. For example, a packet can be forwarded to child nodes in the routing tree. This process then returns to block 1202.

13 illustrates an example computer device 1300 that implements the described systems and methods. In its most basic configuration, computing device 1300 generally includes at least one central processing unit (CPU) 1305 and memory 1310.

Depending on the exact configuration and type of computing device, memory 1310 may be volatile (RAM, etc.), nonvolatile (ROM, flash memory, etc.) or some combination of the two. In addition, computing device 1300 may also have additional features / functions. For example, computing device 1300 may include multiple CPUs. The described method may be executed in any manner by any processing device in computing device 1300. For example, the described process can be executed in parallel by both CPUs.

Computing device 1300 may also include additional storage devices (removable and / or non-removable), including but not limited to magnetic or optical disks or tapes. This additional storage device is shown as storage device 1315 in FIG. 13. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storing information such as computer readable instructions, data structures, program modules or other data. Memory 1310 and storage 1315 are both examples of computer storage media. Computer storage media may include RAM, ROM, EPROM, flash memory or other memory technology, CD-ROMs, digital versatile disks or other optical storage devices, magnetic cassettes, magnetic tapes, magnetic disk storage devices or other magnetic storage devices, Or any other medium that can be used to store desired information or can be accessed by the computing device 1300. Any such computer storage media may be part of computing device 1300.

Computing device 1300 may also include communication device (s) that allow the device to communicate with other devices. Communication device (s) 1340 is an example of communication media. Communication media generally embody computer readable instructions, data structures, program modules or other data on a modulated data signal, such as a carrier or other transmission mechanism, and include all 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 this signal. By way of example, and not limitation, communication media includes wired media such as wired networks or direct wire connections and wireless media such as acoustic, RF, infrared and other wireless media. The term 'computer readable medium' as used herein includes both computer storage media and communication media. The methods described may be encoded in any computer-readable medium in any form of data, computer executable instructions, and the like.

Computing device 1300 may also include input device (s) 1335, such as a keyboard, mouse, pen, voice input device, touch input device, and the like. Output device (s) 1330 such as displays, speakers, printers, and the like may also be included. All of these devices are known in the art and need not be described in detail.

Those skilled in the art will appreciate that the storage device used to store program instructions may be distributed across a network. For example, the remote computer can store an example of the described process as software. The local or terminal computer may download some or all of the software to access the remote computer and run the program. Alternatively, the local computer can download the software as needed or distribute it by executing some software instructions on the local terminal and executing some on the remote computer (or computer network). Those skilled in the art will also appreciate that the use of some of the prior art or software instructions that are well known to those skilled in the art can be performed by dedicated circuitry such as a DSP, a programmable logic array, and the like.

Claims (20)

A computer readable medium storing instructions for causing one node to execute a process of communicating with other nodes, Each node comprises a computing device, each node hosting a respective local application level multicasting (ALM) module, wherein a given node participates in a plurality of multicasting sessions. The nodes participating in the session transmit and receive multicast transmissions to each other via their respective local ALM modules, and the local ALM modules of any nodes are to be used by any application running on this arbitrary node. Each ALM module comprises an application that uses a host node's underlying IP implementation of the host node to send and receive the multicast transmissions between the nodes, The process executed by the local ALM module of the given node, Maintaining information identifying the sessions in which the given node participates, each session comprising a different set of different nodes connected through respective local ALM modules, wherein an application running on the given node Use the local ALM module of the given node to multicast to nodes and the application uses the local ALM module of the given node to receive multicasts from the other nodes in the session; Executing application level routing, wherein the executing step includes: Storing a plurality of different routing maps, each routing map corresponding to another session in which the given node participates through its local ALM module, each routing map describing a route from the corresponding session to another node; ; Receiving packets indicative of the connection status of the nodes, some of the packets being in response to a probe sent by the given node, and in response to changing the state of the node in the first session, accordingly Changing the routing map for a first session; Receiving output packets that are multicast by the application on the given node to the other nodes in the session in which the given node participates—for a given packet, the routing map of the corresponding session is determined of the session to which the packet is to be sent. Used to select a node; And Receiving incoming packets multicasted by the ALM module of the other nodes, and determining whether the given node is the destination of the incoming packet, wherein incoming packets determined to be the destination are at the given node; And if it is determined that the given node is not the destination of incoming packets, the incoming packets are sent to other nodes selected according to the routing map. Maintaining and using the node connection, wherein maintaining and using the node is performed. When a node connection is created, the network is automatically determined by the implementation of the node of the determined IP transport layer protocol, automatically determining an IP transport layer protocol to use among a plurality of IP transport layer protocols including the IP multicast transport layer protocol. Opening a connection, wherein the IP multicast transport layer protocol is selected for at least one node connection and an IP multicast transport layer protocol connection is opened for the at least one node connection; Receiving the incoming packets from the other nodes via the network connection—different node connections to the same node receive incoming packets from the same node using the same network connection to the same node, and the incoming packet Are passed to the application level routing, and some of the incoming packets are received by the IP multicast transport layer protocol connection; Receiving the output packets from the application level routing, and transmitting the output packets to the other nodes via the network connection, wherein different node connections to the same node use the same network connection to the same node; Send the output packets to the same node, some of the output packets being received by the IP multicast transport layer protocol connection; Containing Computer readable medium. The method of claim 1, The process further includes providing the routing map to other nodes, wherein the ALM module of the other nodes uses the routing map. Computer readable medium. The method of claim 1, The routing map is recalculated based on applying at least one of Dijkstra's SPF algorithm and an extended broadest path first algorithm. Computer readable medium. The method of claim 3, The session may be associated with at least one of a video conference, an audio conference, a multimedia conference, an online game, or an event involving multiple users. Computer readable medium. The method of claim 1, The process of determining the IP transport protocol to use is based on a quality of service requirement associated with an output packet. Computer readable medium. The method of claim 1, Some of the incoming packets and output packets correspond to a data stream associated with a video conference. Computer readable medium. A given node configured to communicate with other nodes, The given node and each other node comprises a computing device, wherein the given node and each other node has a local application level multicasting (ALM) module, and the given node is multicasted using its local ALM module. Configured to participate in a session, and nodes within the session send and receive multicast transmissions to each other through their respective local ALM modules, each ALM module configured to be used by any application running on its corresponding node and Each ALM module includes an application running on its node and interfaces with its node's underlying IP implementation to send and receive the multicast transmissions between nodes, The ALM module of the given node, A session layer that maintains information identifying sessions in which the given node participates, each session comprising a different set of different nodes connected through respective local ALM modules, wherein an application running on the given node Use the local ALM module of the given node to multicast to other nodes and use the local ALM module of the given node to receive multicasts from the other nodes in the session; Application level routing layer-The application level routing layer, Use a plurality of different routing maps, each routing map corresponding to a different session in which the given node participates through the ALM module of the given node, each routing map describing a path to nodes in the corresponding session. - Receiving an output packet multicasted to the other nodes in the session in which the node participates by an application on the given node, for a given packet, the routing map of the corresponding session is a node of the corresponding session to send the given packet to Used to select them, A corresponding packet that receives incoming packets multicasted by the ALM module of other nodes and determines whether the given node is the destination of the incoming packets, wherein incoming packets determined to be the destination are executed at the given node. And if it is determined that the given node is not the destination of incoming packets, the incoming packets are sent to other nodes selected according to the routing map; Node connection layer-The node connection layer, When a node connection is created, a network is automatically determined of an IP transport layer protocol to use among a plurality of IP transport layer protocols including an IP multicast protocol and processed by the given node's implementation of the determined IP transport layer protocol. Opening a connection-Some nodes in the session use the IP multicast protocol for the IP transport layer protocol if the IP multicast protocol is available and other nodes in the session use TCP or UDP for the IP transport layer protocol. Used-and, Receiving the incoming packets from the other nodes via the network connection-different node connections to the same node receive incoming packets from the same node using the same network connection to the same node, the incoming packets being Delivered to application level routing, Receive an output packet from the application level routing, and send the output packet to the other nodes via the network connection, but different node connections to the same node to the same node using the same network connection to the same node. Sends the output packet Node containing. The method of claim 7, wherein And a network monitor configured to receive data packets with information regarding the connection states of the nodes associated with the multicasting session and provide the connection states to a routing module that maintains a routing table. Node. 9. The method of claim 8, The routing module is implemented at the application level of the node. Node. The method of claim 7, wherein The node participates in another multicast session using the ALM module, and the ALM module maintains, for each multicast session, an identifier corresponding to the node and an identifier corresponding to the multicast session in which the node participates. Node. The method of claim 7, wherein The ALM module assembles network data packets received over a network level connection to form the incoming packets. Node. 12. The method of claim 11, Further comprising managing a plurality of node connection instances, Each node connection instance corresponds to at least one of the network level connections. Node. The method of claim 12, Each node connection instance is further configured to select a transport protocol for transmitting the data packet to the corresponding node based on a Quality of Service requirement associated with the data packet. Node. 14. The method of claim 13, Each node-connection instance is also configured to choose from among transport protocols, including TCP, UDP, and IP multicast. Node. A method for application level multicasting (ALM) between nodes, Each node comprises a computing device, each node having an application level multicasting (ALM) module, wherein nodes in a multicast session send and receive ALM transmissions to each other through their respective ALM modules, and wherein the ALM The module is configured for use by any application running on the nodes, the ALM module interfaces with the transport protocol provided by the node to send and receive multicast transmissions between the nodes, The method is executed by the ALM module on a node, Maintaining information identifying a multicast session in which the node participates, wherein the multicast session includes a collection of nodes;  Executing application level routing, wherein the executing step includes: Accessing a routing map for the multicast session in which the node participates via the ALM module, the routing map describing a path to each of the nodes in the multicast session; Receiving an output packet multicasted by an application running on the node—for a given output packet, the routing map is used to select nodes of the session to send the packet, one of the other nodes being A final destination of a packet, wherein one of the nodes is an intermediate node that will forward the packet to another node in the multicast session; And Receive incoming packets multicast by the ALM module of the other nodes in the session, pass some of the incoming packets to the application running at the node, and use the routing map to send some of the incoming packets. Identifying other nodes in the multicast session to which is transmitted; And Send and receive, by the ALM module, a portion of the incoming packets and output packets to and from some of the nodes in the session using a transport layer IP multicast module, and another node within the session using TCP or UDP Sending and receiving other incoming and outgoing packets and other portions of output packets therein, wherein the node comprises a TCP transport module, a UDP transport module and the IP multicast transport module for performing transport layer IP multicasting; A network stack comprising an IP module for communicating with a transport layer module of Method for application level multicasting (ALM) between nodes comprising a. 16. The method of claim 15, Determining whether transport layer IP multicasting is available and if so determined, using the transport layer IP multicasting; Method for application level multicasting (ALM) between nodes. 16. The method of claim 15, Determining which transport module to use based on the quality of service criteria; Method for application level multicasting (ALM) between nodes. delete delete delete

Images