CN104219113B - Display and the method for analysis multicast distributed topology figure - Google Patents

Abstract

Display and analyze the topology map algorithm of multicast distribution, adopt the client/server architecture, and the server is divided into communication thread and service thread. The communication thread is responsible for receiving the client's neighbor information and multicast address information and establishing a public data structure, which stores device information, neighbor information connected to the port, and multicast address information, and establishes the relationship between the three. The service thread is responsible for drawing topology diagrams and receiving user queries. Users can view the multicast addresses of devices and query the distribution of specific multicast addresses in the network. The client process cooperates synchronously with the LLDP protocol, GMRP protocol, and IGMP protocol to send neighbor information and multicast address information to the client process, and the client process sends it to the server after processing.

Description

Method for Displaying and Analyzing Multicast Distribution Topology Graph

technical field

The invention relates to a method for displaying and analyzing a multicast distribution topology diagram, which belongs to the field of network communication. The algorithm adopts C/S architecture, a PC in the network is used as the server, and a switch or router in the network is used as the client. The client collects data and reports it to the server. The server generates the topology of the entire network according to the data reported by the client. Figure, while reflecting the multicast distribution in the network.

Background technique

Nowadays, multicast is widely used in the network. Compared with broadcast, multicast has obvious advantages: send at one point, receive at many points, and the receiver can choose to leave or join the multicast group. Unlike broadcasting, devices that do not join a multicast group are not affected by multicasting, which reduces the burden of these settings. One of the problems brought about by the wide application of multicast is that the administrator needs to understand the multicast distribution of the current network, such as the flow path of a specific multicast address in the network, where is the originator of the multicast, and its Where is the final destination and what kind of equipment is passed in the middle. The algorithm proposed by the invention can solve the above problems. It calculates the topological diagram of the entire network, and at the same time displays the multicast distribution on the topological diagram to help users diagnose the network. It intuitively displays the multicast path in the network in real-time, viewing the devices that a particular multicast flow passes through, and the sender and receiver of the multicast flow. This algorithm supports the generation of complex topology graphs. Combined with multicast paths, it can display the multicast streams of specific topological nodes on the generated network topology graph, and at the same time display the topological nodes through which specific multicast streams flow in real time, which is convenient for administrators. monitoring and management.

Contents of the invention

This algorithm adopts the C/S structure, selects a PC in the network as the server, switches and routers in the network as the client, and uses UDP protocol for communication between the client and the server. The server program is divided into two independent threads, namely the communication thread and the service thread. The communication thread is responsible for communicating with the client and receiving the uploaded information from the client, generating a network topology map based on the uploaded information, saving various uploaded data, and establishing the corresponding relationship between each network node and the multicast address. The service thread is mainly used to display the topology map, display the multicast table on each node, and provide query entry for management personnel to use. The two threads use a common data structure to store the data of the topology map and the multicast table. The two threads use a synchronization mechanism. The communication thread receives the data from the client, establishes and maintains the common data structure, and notifies the service after operating the common data structure Thread, the service thread receives the notification, reads the public data structure, and redraws the topology map according to the information stored in the public data structure. The synchronization relationship between the communication thread and the service thread is shown in Figure 1.

The public data structure includes three parts: device linked list and multicast address table. The device list contains device nodes. A device node includes a device label, a device IP address, a device MAC address, a pointer to a port node, and a pointer to the next device node. The port node includes: the port number of the local end, the port number of the opposite end, the neighbor device pointer, and the pointer pointing to the next port node of the same device; the multicast address table includes: the multicast address node, which contains the type of multicast address, Multicast MAC address, multicast IP address, pointer to the multicast device node, and pointer to the next multicast address node. The multicast device node includes a pointer to the device node, a device port vector used by the multicast address, and a pointer to the next multicast device node. The relationship between public data structures is shown in Figure 2.

The server and the client adopt the UDP protocol. When the client finds that the connection changes or the IP/MAC multicast flow changes, it actively uploads information to the server. When the network is stable, very little data needs to be uploaded. When the network changes, it is necessary to send the change information to the server in a timely manner. The server and the client often have short connections, the amount of transmitted data is not large, and the time requirement is high. Therefore, the UDP protocol is adopted, and the UDP server can support more UDP clients than the TCP server. The server confirms the message uploaded by the client, and the communication parties define two data formats: the data format uploaded by the client and the data format confirmed by the server. The uploaded data format includes: serial number, sender IP address, sender MAC address, command type, and command text. One of the uploaded UDP packets contains one or more command types and the text part of the command. The type of command determines the content of the text part. The types of commands and their texts are as follows:

1. The command type is 0x01, which means to join a new neighbor; the text of the command includes: sender's IP address, sender's MAC address, local port number, peer port number, neighbor's IP address, neighbor's MAC address .

2. The command type is 0x11, meaning that the neighbor connection is lost; the text of the command includes: the IP address of the sender, the MAC address of the sender, the port number of the local end, the port number of the peer end, the IP address of the neighbor, and the MAC address of the neighbor.

3. The command type is 0x02, which means adding a new multicast address; the command text includes: sender's IP address, sender's MAC address, type of multicast address, multicast IP address, multicast MAC address, and corresponding port vector.

4. The command type is 0x22, which means leaving the multicast address; the text of the command includes: sender’s IP address, sender’s MAC address, type of multicast address, multicast IP address, multicast MAC address, and corresponding port vector .

First, the server binds the public UDP port agreed by both parties, and waits for the client data to arrive. After receiving the upload message from the client, the server first sends a response message. The content of the response message includes the serial number of the upload message, and then parses the content of the message and operates the public data structure. The server retrieves the sender's IP and MAC address from the message, and queries the corresponding device list accordingly. If the corresponding device node is not found, create a new device node and check the command type.

If the command type is 0x01, use the IP and MAC of the sender device in the command text to find the corresponding sending device node in the device linked list. If the corresponding device can be found, search for the device node pointed to by the port number of the local end in the command text. Whether there is a port node corresponding to the local port number in the port list, if there is a corresponding port node, compare the device node pointed to by the neighbor device pin of the port node with the IP and MAC of the neighbor device in the command text. If they are equal, it proves that the neighbor relationship already exists, and the process ends; if the neighbor device cannot match, then use the IP and MAC of the neighbor device in the command text to find the corresponding device node in the device list, if the corresponding neighbor device node is found, then Modify the neighbor device pointer of the port node to point to the newly found device node. If no neighbor device is found, create a new device node and insert it at the end of the device list, and then the neighbor device pointer of the port node points to the device; if no corresponding The local port number of the sending device, create a port node, insert it at the end of the port list of the device node, use the IP and MAC of the neighbor device in the command text to find the corresponding device node in the device list, if the corresponding neighbor is found The device points the neighbor device pointer of the newly created port node to the found device node. If no neighbor device is found, create a new device node and insert it at the end of the device list. The neighbor device pointer of the port node points to the device.

If the command type is 0x11, use the IP and MAC of the sender device in the command text to find the corresponding sending device node in the device linked list, and if there is no corresponding sending device, end the process. If there is a corresponding sending device, according to the port number of the local end in the command text, check whether there is a corresponding port in the port table pointed to by the device node, and if there is no corresponding port, end the processing; The IP and MAC of the device node pointed to by the pointer are compared with the IP and MAC of neighbor devices in the command text. If the comparison is the same, the device pointer of the port is set to a null pointer; if the comparison is not the same, no processing is performed.

If the type of the command is 0x02, it means that there is a new multicast address added. First, search the multicast address table. If the multicast address node is found, then search for the multicast device node pointed to by the multicast address. If the device of the multicast device node The IP and MAC of the device node pointed to by the pointer are the same as the IP and MAC in the message, then fill the port vector of the node with the port vector in the command text, and end the processing flow; if the corresponding device node is not found, create a new one Insert the device node at the end of the device linked list, fill the port vector of the node with the port vector in the command text, and the device pointer of the multicast device node points to the newly created device. If no multicast address node is found, add a multicast address node; then check whether the device node associated with the multicast address exists, if not, create a new device node, put the device node at the end of the device list, and then follow The port vector in the message creates one or more port nodes, and the port node pointer of the newly created device link list node points to the newly created port node; the device link list device pointer of the new multicast address node points to the newly created device node, and the command The port vector in the body fills the port vector of the node, and the device pointer points to the created device node. If the multicast address node is found, then check whether the device node associated with the multicast address exists, if not, create a new device link list node, put the device link list node at the end of the device link list, and then create it according to the port vector in the message One or more port nodes, the port node pointer of the newly created device link list node points to the newly created port node; the device link list device pointer of the new multicast address node points to the newly created device node, fill this node with the port vector in the command text port vector, and the device pointer points to the created device node. If the device node exists, check whether the port vectors of the multicast device nodes are the same, if not, replace them, and end the process if they are the same. If the multicast address node exists and the corresponding device also exists, check whether the port vectors of the multicast device nodes are the same, if not, replace them, and end the process if they are the same.

If the type of the command is 0x22, it means that the multicast address is left, first look up the multicast address table, if you find a multicast address node, look up the device node pointer it points to, and then compare the multicast device node pointed to by the device pointer Whether the IP address and MAC address are equal to those of the sender of the packet. If it is equal, the port vector in the message is compared with the port vector in the multicast device node bit by bit, if both of the corresponding bits are 1, then the position of the port vector corresponding to the multicast device is 0; if the multicast device The ip address of the multicast device pointed to by the pointer is not equal to the mac in the message, and the next multicast device node pointed to by the next multicast device node pointer is compared. The processing flow of the command received by the server above is shown in FIG. 3 .

As mentioned above, the communication thread on the server is responsible for establishing and maintaining the public data structure. If the communication thread finds any changes in the public data structure, it will notify the service thread to start redrawing the topology map. The server runs for a long time. As time goes by, there will be more and more garbage data in the public data structure. For this reason, the communication thread starts a timer to regularly collect and clean up unnecessary data in the public data structure. The specific cleaning method is as follows:

First clean up orphaned device nodes, which are nodes without any neighbor devices. Scan the device list one by one to check whether the port list pointer pointed to by the device list is a null pointer. If it is a null pointer, it indicates that the device has no neighbors and is an isolated device, then delete the device node; if the port list pointer is not empty, check the Whether the neighbor device pointers of all the port nodes of the device are null pointers, if they are all null pointers, all port nodes of the device can be deleted, and then the device node can be deleted. Secondly, empty the invalid multicast address. An invalid multicast address means that the multicast address is not on any device. The cleaning step is: scan the multicast address table, check whether the multicast device node pointer of the multicast address node is a null pointer, and delete the multicast address node if it is a null pointer.

One of the functions of the service thread is to generate a network topology map, and the depth-first search algorithm and the breadth-first search algorithm can be used to generate the topology map. This algorithm uses depth-first search, and its specific steps are:

A. Set the ring network flag amount to 0 to indicate that there is no loop, and each node of the device linked list is set to have no search completion flag;

B. Look for a device that has not been searched. If the device is not found, exit the whole step. If the device is found, set the current depth and maximum depth of the device to 0, establish the current depth path vector of the current device, the current depth path vector, and the deepest depth path vector, and set all ports of all devices as unvisited flags;

C. Create a stack. The elements of the stack include the type of node, device node, and port node; if the type is equal to 0, it means that the device is stored, and the port node is cleared to indicate that it is meaningless; if the type is equal to 1, the port is stored. At this time, the device Stores the device node where the port is located, and the port stores the port node data, representing the current device node into the stack; the unsearched device node found in step B is pushed into the stack, and the device node is stored in the current depth path vector, and the current depth value is 1;

D. Determine whether the stack is empty, if the stack is empty, set the device node popped out of the stack as the search completed, go to step B; if not empty, take the top element of the stack, if the top element of the stack is a port node, go to step E ; If the top element of the stack is a device node, find the unvisited port node of the device and add it to the stack, set the port as the visited flag, and set the corresponding port of the neighbor device pointed to by the port node as the visited flag; if If the device does not find a port node that has not been visited, it will be popped out of the stack, the current depth will be reduced by one, the current path depth vector will remove the device, and turn to step D; if the port is found, the port will be pushed into the stack, and the port will be set as the visited flag , and at the same time set the corresponding port of the neighbor device pointed to by the port node as the visited flag; if the neighbor device pointer of the port node exists, check whether the device node pointed to by the pointer is the same as the node in the path vector, if the same, go to step G, If they are not the same, add 1 to the current depth, store the neighbor device in the current depth path vector, and then jump to the device node pointed to by the pointer of the neighbor device, push the neighbor device into the stack, and move into the current depth path vector at the same time; go to step F;

E. If the top element of the stack is a port node, get the device where the port is located from the top element of the stack, search for the unvisited port node of the device, find the port and put it on the stack, set the port as the visited flag, and at the same time put the port node The corresponding port of the pointed neighbor device is set as the visited flag, and the neighbor device node pointed to by the port node is pushed into the stack, and turns to step D; the unvisited port node does not exist, pops out of the stack, and turns to step D;

F. Add 1 to the current depth. When the current depth is greater than the maximum depth, update the maximum depth with the current depth, and copy the current depth path vector to the maximum depth vector, and turn to step D;

G. If they are the same, it proves that there is a loop, record and save all the nodes on the loop, set the ring network flag to 1 to indicate that there is a loop, and save the number of nodes that exist in the ring at the same time, give up this deep search, and save the loop All the nodes that appear in , set the search completion flag, and then start looking for the root node of the next depth-first search, which has not appeared in the recorded cycle. Go to step B;

Repeat all the above steps until all the devices have set the search completion flag, through the above operations, you can find the maximum depth of all the devices with this device as the root node. If no repeated nodes are found in the process of finding the maximum depth, the network structure is a tree topology. The algorithm flow for finding the maximum depth is shown in Figure 4.

After finding the maximum depth, start to calculate the distance between the devices. The area occupied by each device is represented by a square. The distance between the devices is equal to the total height of the canvas divided by the maximum depth: assuming that the distance is D, which represents the device The side length of the square is equal to one-eighth of the distance from the device, that is, the side length a=D/8. Each device has 2 hidden canvases, one canvas records the basic information of the device including device identification, IP address, MAC address, and the other canvas records the multicast address associated with each port of the device. At the same time, there is a hidden drawing at both ends of the connection between every two devices, recording the port number of the connected device.

There are two types of network topology diagrams: tree topology and ring topology. According to the depth-first search and breadth-first search, if two or more identical device nodes appear in the search path, it can be judged to be a ring topology, otherwise it is a tree topology. This algorithm judges in the process of finding the maximum depth of the device node Whether the network is a ring or a tree topology, and the topology is drawn in different ways.

The drawing steps of the tree topology are as follows: detect the amount of the ring network flag, if it is 0, it means it is a tree structure, check the maximum depth of each device node, if the depth is the same, compare the mac address of the device, the one with the smaller mac address is preferred , arrange them in descending order, find the first device in the arrangement, place it in the uppermost center of the canvas, and then traverse the path vector of the device, the device currently scanning the subscript points to the beginning of the arrangement, and the arrangement pointed to by the subscript Starting from the first device, draw the next device at a distance D directly below the device, and then draw a line connecting the two devices. Draw all devices on the maximum depth path for this device in this way. When all the device connections of the deepest path of the deepest device are drawn, add 1 to the current scan subscript, and start to draw the device node path of the maximum depth of the device pointed to by the scan subscript: first determine whether the device is in the previously drawn graph It has appeared, if it has appeared, there is no need to draw it separately, find out the node, and then draw it according to the method of drawing the first deepest path. Before drawing the node each time, first judge whether the node already exists, if it already exists, do not need to draw, just connect it with a straight line. If the node has not appeared before, the horizontal offset is D, the vertical offset is H (H=(maximum depth-current node depth)×D), and the node is drawn. In addition, in order to keep the overall balance of the map, paths and equipment are drawn on the left and right sides of the deepest path in turn. Each time the drawing deviates from the D distance downward, and at the same time deviates from the D distance to the left or right. Follow this method until all devices in the queue are drawn. Then scan the device list again, this time according to the breadth-first search, check which device connections are not drawn, if not, use the pointer to connect the two devices. The drawing method of the tree structure is shown in Figure 5

Draw the ring topology map, check the ring network flag, if it is 1, check all the ring network nodes and the number of nodes in the ring network, and find out the ring with the largest number of nodes. If the number of nodes in several rings is the same, the one detected first will be given priority. Set the number of nodes in the ring to the depth H, draw the devices on the ring and connect them, and determine a point in the center of the canvas, with this point as the center of the circle. 1/4 the width of the canvas is the radius, starting to draw the device on the circumference of the circle. Increase the central angle by 360/H degrees each time, draw all the equipment on the ring and connect them in a straight line. Then take the devices on the ring as the source point in turn, do a breadth search, first check whether its neighbor devices appear in the drawn diagram, if they appear and there is no connection between them, directly draw a straight line to connect the two Device; if it has not appeared, take the device on the ring as the center and 1/8 of the width of the canvas as the radius, and draw its non-appearing neighbor devices on the canvas. Each drawing increases a fixed angle of the central angle, assuming it is T=360/the number of neighbors that have not appeared before. After drawing the neighbors of all devices on the ring, follow the same method to use these newly added devices Start drawing for the center of the circle until all sides and devices are present on the canvas.

According to the drawing method of the above-mentioned tree structure and ring structure, when drawing each device, add the IP address, MAC address, description information, and port information on both sides of the device connection at the same position of the hidden layer. After all the devices and the connections between the devices are drawn, scan the multicast address table, add the multicast address to the hidden canvas of the device associated with the multicast address, and also add the port vector of the device corresponding to the multicast address.

The service thread of the server is responsible for the user interface part, which has various functions such as displaying and hiding layers, querying device information, querying multicast address information, and querying multicast paths. When users query the multicast address of a specific device, they only need to redisplay the hidden multicast address canvas of the device. If the user wants to inquire whether a specific multicast address exists in the current network, he first needs to inquire whether the address exists in the multicast address table. If it does not exist in the multicast address table, the query failure information will be returned; The linked list of multicast device pointers pointed to by the multicast address, and then these related devices pointed to by the pointer are highlighted on the canvas, and the connection lines are also boldly displayed. In this way, you can view the distribution of any multicast address in the current network in the network.

The client is responsible for uploading information to the server. The client needs to know the IP address and port number of the server. Generally, the port number remains unchanged, but sometimes the network administrator will change the IP settings of the server, or the administrator will switch the server from a computer Migrate to another computer, at which point all clients will normally need to be reconfigured. The present invention proposes the following solutions to solve this problem: in the running process of the server, it periodically broadcasts its own IP address to the outside, and the client first uses the previously saved IP to detect whether the server is normal when it starts running. Response information to the server, start to receive the broadcast information of the server, get the IP address of the new server from the content of the received broadcast information, then use the new IP address to communicate with the server, and save the IP address until the next operation use this address.

The client needs to upload neighbor information and multicast address information, and the client process and LLDP protocol process, GMRP protocol process, and IGMP protocol process perform synchronous cooperation. There are several types of synchronous collaboration methods such as pipelines, message queues, shared memory, and network sockets. In this algorithm, a message queue is used, where the message type is exactly the same as the command type processed by the server, and the number and meaning of the message type are as follows:

1. Message type 0x01, new neighbor found.

2. Message type 0x02, the previous neighbor lost contact.

3. Message type 0x11, new multicast address found.

4. Message type 0x12, multicast address leaves a port.

The client process needs to cooperate with the LLDP protocol process to obtain neighbor information, and the message queue is used between the two processes for data transmission and synchronization. After the LLDP protocol discovers a new neighbor, it sets the message type to 0x01, and sends the information such as the sender's IP address, the sender's MAC address, the neighbor's IP address, MAC address, and the corresponding port number to the client through the message queue process. After the client process receives the information in the message queue, it assembles it into a UDP message and sends it to the server. After the LLDP protocol finds that the neighbor has lost contact, it sets the message type to 0x02, and sends the sender's IP address, sender's MAC address, neighbor's IP address, MAC address and corresponding port number to the client process through the message queue. After the client process receives the information in the queue, it assembles it into a UDP message and sends it to the server.

The client process needs to cooperate with the GMRP protocol or IGMP protocol process to obtain multicast address information. When the GMRP protocol or IGMP protocol process receives a join message to register a multicast address, set the message type to 0x11, and send the sender’s IP address, sender The MAC address, multicast address type, multicast address, and corresponding port vector are written to the message queue. When the GMRP protocol or IGMP protocol process receives the leave message and cancels the multicast address or when the multicast address timeout is cleared, Set the message type to 0x12, and write the sender's IP address, sender's MAC address, multicast address type, multicast address, and corresponding port vector into the message queue. After the client process receives the information in the queue, it assembles it into a UDP message and sends it to the server. The cooperative relationship between the processes of the server and the client is shown in Fig. 5 .

Description of drawings

Figure 1 Synchronization relationship between communication thread and service thread

Figure 2 Relationship between public data structures

Figure 3 The process of processing commands on the server side

Figure 4 Algorithm flow for finding the maximum depth with the device node as the root

Figure 5 The drawing method of the tree structure

Figure 6 Drawing method of ring structure

Figure 7 The collaborative relationship between the processes of the server and the client

detailed description

First, choose a high-performance server as the server, which has the ability to process a large amount of network data in parallel and has a good man-machine interface to run the server process. The communication thread of the server periodically publishes its own IP address, receives uploaded information from the client, and establishes a public data structure. If there is a change in the public data structure, signal the service thread to refresh the topology map. The server periodically cleans up invalid devices, invalid device neighbor relationships, and currently useless multicast addresses. If the data structure is found to be cleared during the process, it will send a signal to the service thread to refresh the topology map. The service thread on the server side waits to receive the signal, and after receiving the signal, scans the public data structure to generate a new topology map. After generating the topology map, the service thread fills the multicast address information of each device on the hidden layer according to the multicast address table information in the public data structure. At the same time, it receives the query request from the user, and queries the public The data structure and the generated topology map are then opened to show the contents of the hidden layer to the user. When the user queries the multicast address of a specific device, it only needs to display the multicast address information canvas filled with the hidden information of the device. When the user queries the distribution of a specific multicast address, first check whether the specific multicast address exists in the table, if it does not exist in the multicast address table, return query failure information; if the multicast address exists, query the multicast address pointed to Link list of device pointers, and then add dots and highlight the related devices pointed to by the pointers on the canvas, and display the connections in bold. In this way, you can view the distribution of any multicast address in the current network in the network.

Clients include devices that support LLDP, GMRP, and IGMP, generally including smart switches, routers, and intelligent electronic devices. The client needs to modify the LLDP protocol, GMRP protocol, and IGMP protocol, and open their respective message queues. These queues are connected to the client process. The source code of these protocols needs to be modified. In the GMRP protocol and IGMP protocol, it is necessary to register and log out specific multiple When broadcasting the address, the information is sent to the client process through the message queue for processing. When the LLDP protocol discovers a new neighbor device or a neighbor device loses contact, it sends the information to the client process through the message queue for processing. After the client process receives these messages, it sends them to the server through UDP packets for processing.

The above-mentioned content is only a specific example of the present invention, and is not only used to limit the protection scope of the present invention. Any modification, equivalent replacement, improvement and any parameter adjustment within the original scope of the present invention shall be included in the protection scope of the present invention.

Claims (8)

1. The method for displaying and analyzing the multicast distribution topology diagram, adopting the client/server architecture to display the neighbor topology diagram in the network in real time, and reflecting the multicast distribution situation in the network at the same time, is characterized in that: the server and the client are respectively executed Follow the steps below: The server is a server that processes a large amount of network data in parallel and has a good man-machine interface, including two parallel execution threads: communication thread and service thread; their operation steps are as follows: A. The communication thread receives the neighbor information message and the multicast address information message sent by the client; B. The communication thread establishes a public data structure according to the received neighbor information and multicast address information, and the data structure includes device information, port neighbor information, and multicast address information; C. The communication thread notifies the service thread after establishing the public data structure; D. The service thread receives the notification, scans the information of the public data structure, draws the topology map, and adds the multicast address information about the device in the hidden layer at the same time; E. The service thread displays the network topology map in real time and waits for the user's query and display request, and displays the multicast address information according to the request; The client is composed of devices supporting LLDP, GMRP, and IGMP protocols. The operation steps are as follows: F. The client synchronously collects neighbor information and multicast address information through the LLDP protocol process, GMRP protocol process, and IGMP protocol process; G. The collected messages are sent to the client process; H. The client process uploads the message to the server. 2. according to the method for displaying and analyzing multicast distribution topology shown in claim 1, public data structure comprises equipment link list, multicast address link list; Equipment link list is made up of equipment node, and equipment node comprises the pointer pointing to port node, points to A pointer to a device node, the IP address of the device, and the mac address of the device; the port node includes the port number of the local end, the port number of the opposite end, the device node pointer pointing to its neighbor device, and the next port node belonging to the same device Pointer; the multicast device node includes a pointer to the device node, the device port vector used by the multicast address, and a pointer to the next multicast device node; the device, port, and multicast address are connected through the device linked list and multicast address table , Port node establishment association; Its characteristic is: the establishment step of public data structure is as follows: I. The server receives the neighbor information uploaded by the client. The neighbor information includes sender information, port information, and port neighbor information; judge whether the sender of the client exists in the device list. If not, execute step J; if it exists, execute Step K; J. Create a device node and create a port node at the same time, and the port pointer in the device node points to the port node; K. Determine whether the port node exists, if not, create a port node, the port pointer in the device node points to the port node; judge whether its neighbor device exists in the device list, if it exists, the neighbor device of the port node points to the device node ; If there is no execution step L; L. Create a device node, and the neighbor device pointer of the port node points to the device; M. The server receives the multicast address information uploaded by the client. The multicast address information includes sender information and multicast address information. First, it determines whether the multicast address exists. If it does not exist, a multicast address node is created; N. Judging whether the sender device in the multicast address information exists; if it does not exist, then create the device node; O. Determine whether the multicast device node pointed to by the multicast address node exists, if not, create the multicast device node, calculate the port vector, and point the device pointer of the multicast device node to the device node. 3. According to the method for displaying and analyzing multicast distribution topology shown in claim 1, the service thread of the service end is responsible for drawing the topology, and the equipment carries out the depth-first search to obtain the longest path. In the depth search process, if there is a loop, Set the ring network mark amount, record each node in the ring and the total number of ring nodes; it is characterized in that: the step of seeking the maximum depth path of the equipment is: P. Setting the ring network flag amount to 0 shows that there is no loop, and each node of the device linked list is set to have no search completion flag; Q. Look for a device that has not been searched. If the device is not found, exit the whole step; if the device is found, set the current depth and maximum depth of the device to 0, and establish the current depth path vector and maximum depth path vector of the device. At the same time Set all ports of all devices as not accessed flags; R. Create a stack. The elements of the stack include the node type, device node, and port node; if the type is equal to 0, it means that the device is stored; if the type is equal to 1, the port is stored, and the device stores the device node where the port is located. , the port stores the port node data, representing the current device node into the stack; the unsearched device node found in step Q is pushed into the stack, and the device node is stored in the current depth path vector, and the current depth value is 1; S. Determine whether the stack is empty, if the stack is empty, set the device node popped out of the stack as the search completed, go to step B; if not empty, take the top element of the stack, if the top element of the stack is a port node, go to step T ; If the top element of the stack is a device node, find the unvisited port node of the device and add it to the stack, set the port as the visited flag, and set the corresponding port of the neighbor device pointed to by the port node as the visited flag; if If the device does not find a port node that has not been visited, it will be popped out of the stack, the current depth will be reduced by one, the current path depth vector will remove the device, and turn to step S; if the port is found, the port will be pushed into the stack, and the port will be set as the visited flag , at the same time, set the corresponding port of the neighbor device pointed to by the port node as the visited flag; if the neighbor device pointer of the port node exists, check whether the device node pointed to by the pointer is the same as the node in the path vector, if the same, turn to step V, If they are not the same, add 1 to the current depth, store the neighbor device in the current depth path vector, and then jump to the device node pointed to by the pointer of the neighbor device, push the neighbor device into the stack, and move into the current depth path vector at the same time; go to step U; T. If the top element of the stack is a port node, get the device where the port is located from the top element of the stack, search for the unvisited port node of the device, find the port and put it on the stack, set the port as the visited flag, and put the port node The corresponding port of the pointed neighbor device is set as the visited flag, and the neighbor device node pointed to by the port node is pushed into the stack, and turns to step S; the unvisited port node does not exist, pops out of the stack, and turns to step S; U. Add 1 to the current depth. When the current depth is greater than the maximum depth, update the maximum depth with the current depth, and copy the current depth path vector to the maximum depth path vector, and turn to step S; V. If they are the same, it proves that there is a loop, record and save all the nodes on the loop, set the ring network flag to 1 to indicate that there is a loop, and save the number of nodes that exist in the ring at the same time, give up this deep search, and save the loop All the nodes appearing in , are set as the search completion mark, and then start to search for the root node of the next depth-first search, which has not appeared in the recorded cycle; turn to step Q. 4. according to the method for displaying and analyzing the multicast distribution topology shown in claim 3, it is characterized in that: if there is no loop in the depth-first search, the longest path obtained by the depth-first search of all devices is arranged in descending order, and the arrangement Compare the depth of the path with the mac address of the device, and the depth is prioritized. If the depth is the same, compare the mac address, and the one with the smaller mac address is given priority; then draw the device and connection with the longest depth first, and then draw the device and connection with the second longest depth If the device has been drawn before, it is not necessary to draw the direct connection; repeat these operations until all the devices and lines are drawn. 5. according to the method for displaying and analyzing the multicast distribution topology shown in claim 3, it is characterized in that: if there is a loop in the depth-first search, then at first find the loop with the largest number of nodes in the loop, and then use the canvas's The middle is the logical center of the circle, with a certain length as the radius, incrementing a fixed central angle each time, drawing the equipment on the longest ring path in turn on the circumference, and connecting the equipment with a straight line; then use these equipment as the center of the circle, and at the same time Perform a breadth search on these devices, draw the searched devices on the circumference in turn, and connect them in a straight line; repeat these operations until all devices and neighbor relationships are drawn. 6. according to the method for displaying and analyzing the multicast distribution topological diagram shown in claim 4 or 5, it is characterized in that: after drawing the topological diagram, scan the multicast address table, obtain pointing to the equipment associated with the multicast address, in the equipment Add the multicast address in the hidden layer of the . 7. according to the method for displaying and analyzing the multicast distribution topology diagram shown in claim 6, it is characterized in that: whether the user wants to inquire whether a specific multicast address exists in the current network, at first need to inquire whether this address exists in the multicast In the address table, if it does not exist in the multicast address table, the query failure information will be returned; if it exists, query the linked list of device pointers pointed to by the multicast address, and then highlight the related devices pointed to by the pointer on the canvas. The lines are also displayed in bold, so that you can view the distribution of any multicast address in the current network in the network. 8. according to the method for displaying and analyzing multicast distribution topology shown in claim 1, it is characterized in that: client process needs to carry out synchronization with LLDP protocol process, GMRP protocol process, IGMP protocol process to collect neighbor information and multicast address Information, the above processes carry out data transmission and synchronization through the message queue; when the LLDP protocol process finds that the neighbor has changed, it sends the changed message to the client process for processing; when the GMRP protocol process and the IGMP protocol process find that the multicast address has registered or When logging out, the changed message is sent to the client process for processing, and the client processes the message after receiving it and sends it to the server for processing through the UDP protocol.