Knowledge, application and programming of IP multicast technology

With the rapid development of the global Internet (Internet), the number of Internet users is growing exponentially. The ratio of Internet-dominated Data Communication in the total amount of communication services is rapidly increasing, internet services have become the most rapidly developing and competitive multimedia communication industry. The dramatic increase in Internet transmission and processing capabilities has led to an increasing number of online applications, especially the development and maturity of video and audio compression technologies, making the online video and audio business one of the most important services on the Internet.

Compared with normal services, on-demand video/audio (VOD), videophone, and video conferencing services implemented on the internet, these services have the characteristics of large data volume, high latency sensitivity, and long duration. Therefore, the minimum time and space are used to transmit and solve the problems of high network utilization, fast transmission speed and real-time performance required by the video/audio service, we need to adopt forwarding technology and QoS service assurance mechanism different from traditional unicast and broadcast mechanisms. IP multicast technology is the key technology to solve these problems.

I. Concepts of IP multicast technology

IP multicast (also called multicast or multicast) technology allows one or more hosts (Multicast sources) to send a single packet to multiple hosts (once and simultaneously) TCP/IP network technology. Multicast, as a one-to-multiple-point communication, is one of the effective ways to save network bandwidth. In Network Audio/Video Broadcast applications, when a node signal needs to be transmitted to multiple nodes, whether it is through repeated point-to-point communication or broadcast, network bandwidth is a serious waste. Only multicast is the best choice. Multicast enables one or more multicast sources to send only data packets to a specific multicast group, and only the host that joins the multicast group can receive data packets. Currently, IP multicast technology is widely used in network audio/video broadcast, Aod/VOD, network video conferencing, multimedia distance education, and "push" technology (such as stock quotations) and Virtual Reality games.

Ii. Basic knowledge of IP multicast technology

1. IP multicast address and multicast group

IP multicast communication must depend on the IP multicast address. In IPv4, It is a Class d ip address ranging from 224.0.0.0 to 239.255.255.255, it is divided into three categories: Local Link multicast address, reserved multicast address, and management permission multicast address. The local link multicast address ranges from 224.0.0.0 ~ 224.0.0.255 is the address reserved for the routing protocol and other purposes. The Router does not forward IP packets in this range. The reserved multicast address is 224.0.1.0 ~ 238.255.255.255, which can be used for global (such as Internet) or network protocols. The management permission multicast address is 239.0.0.0 ~ 239.00000000255, which can be used within an organization. It is similar to a private IP address and cannot be used on the Internet. It can restrict the multicast range.

All Hosts that receive multicast data packets using the same IP address constitute a host group, also known as multicast groups. Members of a multicast group change at any time. A host can join or leave a multicast group at any time. The number and geographic location of multicast group members are not limited, A host can also belong to several multicast groups. In addition, a host that does not belong to a multicast group can also send data packets to the multicast group.

2. multicast distribution tree

To transmit multicast data to all the receiving hosts, the multicast distribution tree is used to describe the path of IP multicast in the network. The multicast distribution tree has two basic types: the active tree and the shared tree.

The source tree uses multicast sources as the root of the source tree. The branches of the source tree form a distribution tree that reaches the receiving host through the network, because the source tree runs through the network in the shortest path, therefore, it is also called the Shortest Path Tree (SPT ). The shared tree uses one of some selectable multicast routes in the multicast network as the public root of the shared tree. This root is called the convergence point (RP ). The shared tree can be divided into one-way shared tree and two-way shared tree. One-way shared tree means that multicast data streams must pass through the shared tree from the root to the multicast receiver. A two-way shared tree means that multicast data streams do not pass through the shared tree.

3. Reverse path forwarding

Reverse route forwarding (RPF) is the basis for the multicast data forwarding process in Multicast Routing Protocol. Its working mechanism is that when multicast information passes through the active tree, the multicast router checks the Multicast Source Address of the multicast data packet to determine whether the interface that the multicast data packet goes through is on the source branch. If yes, the RPF check succeeds, multicast data packets are forwarded. If the RPF check fails, the multicast data packet is discarded.

4. Internet multicast trunk (mbone) Network

The Internet multicast trunk (mbone) network is composed of a series of interconnected subnet hosts and routers that support IP multicast. It can be viewed as a virtual network built on the upper layer of the Internet physical network. In this virtual network, multicast information flows from multicast sources can be transmitted directly between vro groups that support IP multicast, point-to-Point Tunneling Technology is required between multicast router groups and non-multicast router groups.
 

 

Iii. IP multicast routes and their Protocols

1. Basic Types of IP multicast routes

A common idea of multicast routing is to construct an extended distribution tree between multicast group members. The IP multicast traffic on a specific "sending source, target group" is transmitted from the sending source to the recipient through this extension tree, the extension tree connects all hosts in the multicast group. Different IP Multicast Routing Protocols use different technologies to construct these multicast extension trees. Once this tree is constructed, all multicast traffic will be transmitted through it.

According to the distribution of multicast group members in the network, IP multicast routing protocols can be divided into the following two basic types. First, assume that multicast group members are densely distributed in the network. That is to say, most subnets in the network contain at least one multicast group member, and the network bandwidth is large enough, this multicast routing protocol, called dense-mode, relies on broadcast technology to push data to all routers in the network. Intensive mode routing protocols include the distance vector Multicast Routing Protocol (dvmrp: Distance Vector Multicast Routing Protocol) and multicast Open Shortest Path First (mospf: multicast Open Shortest Path First) and dense mode independent multicast protocol (PIM-DM: Protocol-Independent Multicast-dense mode) and so on.

The second type of multicast routing assumes that multicast group members are sparse and scattered in the network, and the network cannot provide sufficient transmission bandwidth, for example, a large number of users in many different regions are connected over ISDN lines on the Internet. In this case, broadcast will waste a lot of unnecessary network bandwidth, which may cause serious network performance problems. Therefore, the Sparse Mode Multicast Routing Protocol must rely on technologies with routing selection capabilities to establish and maintain multicast trees. Sparse Mode mainly includes the core tree-based multicast protocol (CBT: core based tree) and sparse mode independent protocol multicast (PIM-SM: Protocol-Independent Multicast-Sparse Mode ).

2. Intensive mode Protocol

(1) Distance Vector Multicast Routing Protocol (dvmrp)

The first routing protocol that supports multicast is the distance vector multicast routing protocol. It has been widely used in the multicast Backbone Network mbone.

Dvmrp builds different distribution trees for each sending source and Target Host group. Each distribution tree is a minimum extended distribution tree that uses multicast transmission sources as the root and receives the target host as the leaf. This distribution tree provides a shortest path between the sending source and each multicast receiver in the group. The shortest path in the unit of "Number of hops" is the measurement of dvmrp. When a sending source needs to send messages to multicast groups, an extended distribution tree is created based on this request, we also use the broadcast and Trim Technology to maintain this extended distribution tree.

When a vro receives a multicast packet, it first checks its unicast route table to find the shortest path interface of the Multicast Group Sending source. If this interface is the interface that the multicast packet arrives, then, the vro records the multicast group information to its internal route table (indicating the interface that the group data packet should be sent ), in addition, the multicast packet is sent to the nearby router except the router that receives the packet. If the arrival interface of the multicast packet is not the shortest path from the router to the sending source, the packet will be discarded. This mechanism is called the reverse-path broadcasting mechanism, which ensures that no loops are generated in the constructed tree and is the shortest path from the sending source to all recipients.

Dvmrp works well for intensive multicast groups in sub-networks, but for multicast groups that are distributed in a large range of regions, periodic broadcast behavior can cause serious performance problems. Dvmrp does not support sparse and scattered multicast groups in large networks.

(2) mospf)

Open Shortest Path First (OSPF) is a unicast routing protocol that transmits data packets over the minimum overhead path. The overhead here is a measure of the link status. In addition to the number of hops in the path, other network performance parameters that affect the path overhead include Load Balancing information and applications.ProgramRequired QoS.

Mospf is designed for unicast routing multicast. Mospf depends on OSPF as the unicast routing protocol, just as dvmrp also includes its own unicast protocol. In an OSPF/mospf network, each vro maintains the latest full network topology. This "link status" information is used to build a multicast distribution tree.
 

 

Each mospf router periodically collects multicast group member information through the IGMP protocol. The information and the link status information are sent to all other routers in the routing domain. Routers update their internal connection status based on the information they receive from the neighboring routers. Because each vro knows the topology of the entire network, it can independently calculate a minimum overhead extension tree, and use multicast sending sources and multicast group members as the root and leaf of the tree. This tree is the path used to send multicast streams from the sending source to multicast group members.

(3) Independent Multicast intensive mode protocol (PIM-DM)

The Independent Multicast Protocol (PIM) is a standard multicast routing protocol. It can provide scalable Inter-Domain multicast routing over the Internet without relying on any unicast protocol. Pim has two operation modes: dense distribution multicast group mode and sparse distribution multicast group mode. The former is called Independent Multicast intensive mode protocol (PIM-DM ), the latter is known as the standalone Multicast Sparse Mode protocol (PIM-SM ).

The PIM-DM is somewhat similar to dvmrp, both of which use the reverse path multicast mechanism to build the distribution tree. The main difference between them is that Pim is completely independent of the unicast routing protocol in the network, and dvmrp is dependent on a related unicast routing protocol mechanism, and the PIM-DM is simpler than dvmrp.

PIM-DM protocols are also data-driven like all dense-mode routing protocols. But since the PIM-DM does not rely on any unicast routing protocol, a router receiving port (that is, the port that returns to the shortest path of the source) the received multicast packet is sent to all downstream interfaces until the unneeded branches are trimmed from the tree. Dvmrp can use the topology data provided by unicast protocol to selectively send data packets in the next row in the tree build phase, PIM-DM is more inclined to simplicity and independence, and even do not hesitate to increase the additional overhead caused by data packet replication.

2. Sparse Mode Multicast Routing Protocol

 

When multicast groups are centrally distributed in the network or the network provides sufficient bandwidth, the intensive mode multicast routing protocol is an effective method, when multicast group members are sparse in a wide range of regions, another method is required: The Sparse Mode Multicast Routing Protocol controls multicast traffic to the link path connected to multicast group members, instead of "leaking" to unrelated link paths, this not only ensures data transmission security, but also effectively controls the total traffic in the network and the load of the router.

(1) Core tree-based multicast protocol (CBT)

Unlike dvmrp and mospf, the shortest path tree is constructed for each "Send source and target group", the CBT protocol only creates one tree for all members in the group to share, this tree is also called a shared tree. The multicast traffic of the whole multicast group is sent and received on the shared tree, regardless of the number or location of the source. The use of this shared tree can greatly reduce the multicast status information in the router.

The CBT share tree has a core router used to build this tree. The vro to be added sends a join request to the core vro. After receiving the join request, the core router returns a confirmation along the reverse path, which constitutes a branch of the tree. Incoming request packets do not need to be transmitted to the core router until they are confirmed. If a request packet arrives at a router on the tree before arriving at the core router, the router receives the request packet and does not send it forward and confirm the request packet. The router that sends the request is connected to the shared tree. CBT distributes multicast traffic to a minimum number of links instead of a source-based sharing tree. Traffic concentrated on the core router may cause some multicast routing problems. Some versions of CBT support the use of multiple multicast cores, and load balancing is better than that of a single multicast core.

(2) Independent Multicast Sparse Mode protocol (PIM-SM)

Similar to CBT, The PIM-SM is designed to restrict multicast to the router that needs to be sent and received. The PIM-SM builds a multicast distribution tree around a router called a centralized point (RP: rendezvous point. This centralized point plays the same role as the CBT core router. the receiver can query the new sending source at the centralized point. But PIM-SM is more flexible than CBT, CBT tree is usually multicast group sharing tree, the independent receiver in the PIM-SM can choose to build a group sharing tree or shortest path tree.

The PIM-SM protocol first creates a group of shared trees for multicast fabric. This tree is constructed by the sender and receiver connecting to the centralized point, just like the sharing tree built around the core router by the CBT protocol. After the sharing tree is established, a receiver (actually the router closest to the receiver) can choose to change the connection to the sending source through the Shortest Path Tree. This operation is completed by sending a PIM request to the sending source. Once the shortest path from the sending source to the receiver is established, the external branches of the RP are trimmed.

Iv. Programming of IP Multicast Applications
In practical applications, programmers usually need to compile their own underlying network applications to achieve the underlying communication on the Internet, such as the specific implementation of the IP multicast communication function. Compiling underlying network applications usually relies on network data communication programming interfaces, while network programming interfaces provided in different operating systems are different, for example, in Microsoft Windows, the network programming interface is Windows Socket (Windows Socket, Winsock ).

Winsock provides programming interfaces for multiple communication protocols, including TCP/IP and IPX. Different Windows versions support different Winsock versions. Earlier versions such as Windows 95 only support programming under winsock1.1 (16-bit) (you can install related software packages to enable winsock2.0 ), windows 98, Windows NT4.0, and Windows 2000 directly support winsock2.0 (32-bit ). Winsock2.0 is an extension of winsock1.1. In addition to being compatible with winsock1.1 APIs, it also defines a set of protocol-independent APIs that support IP multicast.

The general steps for implementing IP multicast using Winsock 2.0 are as follows:

1. initialize Winsock Resources

Before using WinSock, you must call the wsastartup () function to initialize Windows Sockets DLL. It allows applications or DLL to specify the version required by the Windows Sockets API.

2. Create a socket

You can call the wsasocket () function to create a socket using the UDP protocol. It is the initial socket that is added to the multicast group, and the data will be sent and received in the future. For IP multicast communication, you can set the parameter dwflags to the bitwise and of wsa_flag_multipoint_c_leaf, cosine, and wsa_flag_overlapped, indicating that IP multicast communication is "rootless" at the control and data layers ", only leaf nodes exist. They can join any multicast group, and data sent from a leaf node is transmitted to each leaf node (including its own ); the created socket has overlapping attributes.

3. Set socket options

Call the setsockopt () function to set the so_reuseaddr option for the socket to allow the socket to be bound to an existing address.

4. Bind a socket

Call the BIND () function to bind the socket to associate the created socket with the local address and local port. For multicast communication, the same port is usually used to send and receive data.

5. Set the multicast Socket mode

The command code sio_multicast_loop of the wsaioctl () function is used to enable or disable multicast communication. CAN communication traffic be received on the same socket (that is, multicast return ). It is worth noting that in Windows 95/98/NT 4, multicasting is allowed by default, but cannot be set to prohibit; otherwise, errors may occur; only in Windows 2000 or later versions, to enable or disable multicast return.

The command code sio_multicast_scope of the wsaioctl () function is used to set the multicast propagation range, that is, TTL. When a multicast router forwards a multicast packet, the TTL value in the packet is reduced by 1. If the TTL of the packet is reduced to 0, the router discards the packet. The value of TTL is the maximum number of multicast routers that can be accessed by multicast data. For example, if the TTL value is 0, multicast can only spread between multiple sockets on the local host, but not to the "network cable". The TTL value is 1 (default ), when multicast data encounters the first vro, it is "ruthlessly discarded" and cannot be transferred out of the local network, that is, only multicast members in the same network can receive multicast data.
6. Join a multicast group

Call the wsajoinleaf () function to join a multicast group and specify the role (sender/receiver ). When calling, the parameter dwflags can specify the socket as the sender (jl_sender_only), receiver (jl_receiver_only), or both (jl_both ). After the call is successful, a multicast socket is returned. When the closesocket () function is called to close the socket, the multicast group is left. In this case, you can call the wsajoinleaf () function to join the multicast group again. Note that receiving and sending multicast group data cannot be completed on this socket.

7. send data to multicast groups

Call the sendto () function to send multicast data to a specified multicast group on a specified UDP socket. During the call, the parameter to should point to the IP address of the multicast group. It is worth noting that if an application only wants to send data to multicast groups, it does not have to join a multicast group.

8. Wait for the event

Call the wsaasyncselect () function to place the socket in non-blocking mode. Then, the application can receive network event notifications Based on Windows messages on the socket. For example, if the Levent value is fd_read, the application can receive the notification "data is waiting to be read" on the socket.

9. receive data from Multicast Groups

Call the recvfrom function to read the input data on the specified UDP socket. Generally, the same port is used for sending and receiving data in multicast communication. Therefore, the sending and receiving sockets are the same.

10. Close the socket and release Winsock resources.

After multicast communication ends, call the closesocket () function to disable multicast sockets and UDP sockets, and then call the wsacleanup () function to end the use of Windows Sockets DLL.

V. , Application instance
To illustrate the application of IP multicast technology, I am in Visual C ++. NET environment, a simple IP Multicast Application Based on Windows Socket 2 is designed. Through this example, the reader can master the general method of IP multicast application design. The specific design method of this program is as follows:

1. Create a dialog box-based MFC project cmulticastsocket in Visual Studio. NET. Note that do not select "Windows Socket" in "advanced functions" Settings, because MFC only supports Windows Socket 1 and does not support Windows Socket 2. To enable WinSock 2 API programming, the program should contain the "winsock2.h" header file and add the static library ws2_32.lib to the project, the static library should be set in the "linker", "input", and "additional dependencies" of the project properties.

2. In the dialog box (Class Name ccmulticastsocketdlg), set its caption to "WinSock 2 multicast application" and add the following controls:

Static text: caption is "received information :";
Edit box: the ID is idc_receive_edit. The attribute values of read only, auto vscroll, vertical scroll, and Multiline are both true.
Static text: caption is "sent information :"
Edit box: ID: idc_send_edit
The first button: caption is "Join multicast group (& J)", and ID is idc_join_button
The second button: caption is "Multicast sending (& S)", and ID is idc_send_button
The third button: caption is "Exit multicast group (& L)", and ID is idc_leave_button
Fourth button: caption is "exit (& Q)", ID is idc_quit_button

Add the associated cstring variables m_sendmessage and m_receivemessage to the two edit boxes, and add corresponding message processing functions for the four buttons; add a timer message and its message processing function to the dialog box.

3. Add a new dialog box resource, set its caption to "Join multicast group", retain the default two button controls, and add the following controls:

Static text: caption is "IP multicast group address :"
Edit box: ID: idc_ipaddress_edit
Static text: caption is "IP multicast port :"
Edit box: ID: idc_port_edit
Static text: caption is "survival time :"
Edit box: ID: idc_ttl_edit
Check box: caption is "Multicast return:", ID is idc_loopback_check, and left text attribute value is true.

Add a new class cjoingroupdlg to the dialog box. The base class is cdialog. Then, add
Associated variables: csting m_ipaddress, uint m_nport, and uint m_nttl; added the associated bool type variable m_loopback to the check box.

4. Add the header file of cjoingroupdlg before the cmulticastsocketdlg. h file: # include "joingroupdlg. h" and add a cjoingroupdlg Instance Object m_joindlg to the ccmulticastsocketdlg class.

5. to receive network event notifications in the dialog box, you should add a user-defined message and message processing function. The implementation method is as follows: In cmulticastsocketdlg. the preceding custom message of the hfile: # define wm_sock_msg (wm_user + 166), and describes the message processing function in the afx_msg block: afx_msg lresult onsocketmsg (wparam, lparam ); in cmulticastsocketdlg. in the message ing block in the CPP file, use the on_message (wm_sock_msg, onsocketmsg) macro command to map the message to the message processing function, and implement the message processing function: lresult ccmulticastsocketdlg :: onsocketmsg (wparam, lparam ){...}.

Main ProgramCodeSee the program list. For detailed descriptions of related functions, see the Microsoft msdn help system. To save space, some automatically generated and error handling code is omitted in the program.

Program list:

// cmulticastsocketdlg. CPP: implementation file
# include "stdafx. H "
# include" winsock2.h "
# include" cmulticastsocket. H "
# include" cmulticastsocketdlg. H "
......
DWORD cbret;
socket sock, sockm; file: // UDP socket, multicast socket
bool bflag, bjoin;
sockaddr_in local, remote, from; file: // IP address and port pointing to the local, multicast group, and data source respectively
int fromlen;
char receivebuf [32000]; file: // receiving buffer
bool bdatareceived;
......
begin_message_map (ccmulticastsocketdlg, cdialog)
......
on_bn_clicked (idc_join_button, response)
on_bn_clicked (idc_leave_button, response)
Reset (idc_quit_button, response)
on_bn_clicked (idc_send_button, response)
on_wm_timer ()
on_message (wm_sock_msg, onsocketmsg)
end_message_map ()

bool ccmulticastsocketdlg: oninitdialog ()
{< br> cdialog: oninitdialog ();
......
settimer (1,100, null); file: // set the timer
fromlen = sizeof (from);
bdatareceived = true;
bjoin = false;
return true; // return true unless the control focus is set.
}< br> ......
void ccmulticastsocketdlg: onbnclickedjoinbutton () file: // Add to multicast group
{< br> If (m_joindlg.domodal () = idok)
{< br> word wversionrequested;
wsadata;
int Beijing zhongqing;
wversionrequested = makeword (2, 2 );
Beijing zhongqing = wsastartup (wversionrequested, & wsadata); file: // initialize Winsock2 resources
If (Beijing zhongqing! = 0) {
afxmessagebox ("Windows Socket dynamic link library cannot be loaded, mb_ OK");
return;
}< br> If (lobyte (wsadata. wversion )! = 2 | hibyte (wsadata. wversion )! = 2) {
afxmessagebox ("Winsock DLL does not support version 2.0, mb_ OK");
wsacleanup ();
return;
}< br> file: // create a socket
sock = wsasocket (af_inet, sock_dgram, ipproto_udp,
(lpwsaprotocol_info) null, 0, wsa_flag_overlapped
| wsa_flag_multipoint_c_leaf | wsa_flag_multipoint_d_leaf);

Bflag = true; file: // set socket options so that the socket can be a reusable port address
Setsockopt (sock, sol_socket, so_reuseaddr, (char *) & bflag, sizeof (bflag ));

File: // bind the socket to the user-specified port and default Interface
Memset (& Local, 0, sizeof (local ));
Local. sin_family = af_inet;
Local. sin_port = htons (ushort) m_joindlg.m_nport );
Local. sin_addr.s_addr = htonl (inaddr_any );
BIND (sock, (struct sockaddr far *) & Local, sizeof (local ));

File: // set the multicast datagram propagation range (TTL)
Wsaioctl (sock, sio_multicast_scope, & m_joindlg.m_nttl, sizeof (INT ),
Null, 0, & cbret, null, null );
File: // sets the lookback)
Bool nloopback = m_joindlg.m_loopback;
Wsaioctl (sock, sio_multipoint_loopback, & nloopback, sizeof (nloopback ),
Null, 0, & cbret, null, null );

Memset (& remote, 0, sizeof (remote ));
Remote. sin_family = af_inet;
Remote. sin_addr.s_addr = inet_addr (m_joindlg.m_ipaddress );
Remote. sin_port = htons (m_joindlg.m_nport );
File: // Add to the specified multicast group and specify as both a sender and a receiver (jl_both)
Sockm = wsajoinleaf (sock, (sockaddr *) & remote, sizeof (remote ),
Null, null, jl_both );
Wsaasyncselect (sock, m_hwnd, wm_sock_msg, fd_read); file: // registers network messages and network events
Bjoin = true;
}
}

Void ccmulticastsocketdlg: onbnclickedsendbutton () file: // multicast sending
{
If (bjoin ){
Updatedata (true );
Const char * strmessage = lpctstr (m_sendmessage );
Int nsize = m_sendmessage.getlength () + 1;
Sendto (sock, strmessage, nsize, 0, (sockaddr *) & remote, sizeof (remote ));
}
Else
Afxmessagebox ("please join the multicast group first! ");
M_sendmessage = "";
Updatedata (false );
}

Void ccmulticastsocketdlg: onbnclickedleavebutton ()
{File: // exit multicast group
Closesocket (sockm );
Closesocket (sock );
Wsacleanup ();
M_sendmessage = "";
M_receivemessage = "";
Bdatareceived = true;
Bjoin = false;
Updatedata (false );
}

Void ccmulticastsocketdlg: onbnclickedquitbutton ()
{File: // exit
Destroywindow ();
}

Void ccmulticastsocketdlg: ontimer (uint nidevent) file: // timer processing function to implement regular update of received information
{
If (bdatareceived)
{
M_receivemessage + = receivebuf;
M_receivemessage + = "\ r \ n ";
Bdatareceived = false;
Updatedata (false );
}
Cdialog: ontimer (nidevent );
}

Lresult ccmulticastsocketdlg: onsocketmsg (wparam, lparam)
{
File: // retrieves network events
Switch (wsagetselectevent (lparam )){
Case fd_read:
Recvfrom (sock, receivebuf, 32000,0, (sockaddr *) & from, & fromlen );
Bdatareceived = true; file: // sets the flag of the received message.
Break;
}
Return true;
}

Vi. Application of IP multicast technology

IP multicast applications can be divided into three types: point-to-point applications, multi-point-to-point applications, and multi-point-to-point applications.

1. Point-to-point applications

Point-to-point applications refer to the Application Form of one sender and multiple receivers. This is the most common form of multicast applications. Typical applications include media broadcast, media push, information caching, event notification, and status monitoring.

Media broadcast: events on schedule, such as presentations, presentations, and meetings. Traditional media distribution methods generally use television and broadcasting. This type of application usually requires one or more data streams at a constant rate. When multiple data streams (such as voice and video) are used, they usually need to be synchronized, there are different priorities for each other. They usually require high bandwidth and low latency jitter, but they do not require high absolute latency.

Media push: such as news titles, weather changes, sports scores, and other non-commercial key dynamic changes. They require low bandwidth and no latency requirements.

Information Caching: such as website information, code execution, and other file-based distributed replication or cache updates. They generally require bandwidth and latency.

Event Notification: such as network time, multicast session schedule, random numbers, keys, Configuration updates, network alarms for effective ranges, or other useful information. They have different bandwidth requirements, but generally have relatively low requirements for latency.

Status Monitoring: such as stock prices, sensing devices, security systems, production information, or other real-time information. Such bandwidth requirements vary according to the sampling period and precision, and may have a constant rate bandwidth or burst bandwidth requirements. Generally, the bandwidth and latency requirements are average.

2. Multi-Point-to-point applications

Multi-Point-to-point applications refer to the application form of multiple senders and one receiver. It is usually a two-way Request Response application, and any end (multiple points or points) may initiate a request. Typical applications include resource search, data collection, online bidding, information inquiry, and juke box.

Resource search: for example, if a service is located, it requires a low bandwidth and a low latency.

Data collection: it is a reverse process of monitoring applications on the status of a point-to-point application. It may send data back to a data collection host by multiple sensing devices. Bandwidth requirements vary according to the sampling period and accuracy, and may have a constant rate bandwidth or burst bandwidth requirements. Generally, such applications require a moderate bandwidth and latency.

Online Auction: The auction product, and multiple bidders send the price back to the auction.

Information Inquiry: The Inquirer sends an inquiry, and all the inquirers return a response. This usually has low bandwidth requirements and is not sensitive to latency.

Juke Box: for example, you can use the quasi-on-demand (near-on-demand) Audio/Video reverse storage. Generally, the recipient uses an out-of-band protocol (such as HTTP, RTSP, or SMTP, Or multicast) to send a reverse request to a scheduling queue. It has high bandwidth requirements and generally has low latency requirements.

3. Multi-Point to multi-point applications

Multi-Point-to-Multi-Point application refers to the application form of multiple senders and multiple receivers. Generally, each receiver can receive data sent by multiple senders, and each sender can send data to multiple receivers. Typical applications include multi-point conferences, resource synchronization, parallel processing, collaborative processing, remote learning, discussion groups, Distributed Interactive Simulation (DIS), multiplayer games, and jam sessions.

Multi-Point Meeting: Generally, audio/video and text applications constitute multi-point meeting Applications. In multi-point meetings, different data streams have different priorities. Traditional multi-point conferences use dedicated multi-point control units to coordinate and allocate them. Multicast can be directly sent to all receivers by any single sender. The multi-point control unit is used to control the current voice. Such applications require high bandwidth and latency.

Resource synchronization: synchronization of distributed databases such as schedules, directories, and information. They generally require bandwidth and latency.

Parallel Processing: such as distributed parallel processing. It has high requirements on bandwidth and latency.

Collaborative processing: such as editing shared documents. It generally requires bandwidth and latency.

Remote Learning: This is actually a media broadcast application that supports upstream data streams (allowing students to ask questions to teachers. It generally requires bandwidth and latency.
Discussion Group: similar to text-based multi-point meetings, it can also provide some simulated expressions.

Distributed interaction simulation (DIS): It has high requirements on bandwidth and latency.

Multiplayer games: multiplayer games are a simple Distributed Interactive Simulation with discussion groups. It has high requirements on bandwidth and latency.

Jam session: This is an audio encoding sharing application. It has high requirements on bandwidth and latency.

 

IP multicast brings many new applications and reduces network congestion and server load. Currently, IP multicast is not widely used, but it can reduce bandwidth usage, server load, and improve data transmission quality, especially for multimedia applications that require a large amount of bandwidth, such as audio and video. This new technology has become a hot topic in the network field and will fundamentally change the network architecture.