Browse Prior Art Database

Network performance analysis through recursive remote execution

IP.com Disclosure Number: IPCOM000015062D
Original Publication Date: 2001-Sep-25
Included in the Prior Art Database: 2003-Jun-20
Document File: 1 page(s) / 41K

Publishing Venue

IBM

Abstract

Current network analysis tools do a good job of measuring network performance between two points. But that makes analyzing a network a very tedious process. There are two basic aspects to this design that work together to provide the funciton that we need. The first basic function is a GUI based upon a Network diagram (or we might just stage the function in as a hierarchy first) of the network. The second basic function is a "recursive crawling" analysis program. We are aware that some current network analysis tools give a GUI that provides a view of the network. But the tools that we have seen all show the network nodes from the point of view of the analysis tool. In our design, the GUI will show the network from a perspective of what connections are of interest. Not necessarily the physical network. For example, in a LAN of 6 nodes (a, b, c, d, e, f) all nodes may be attached in (token) ring, or switched. Logically each one can connect to all of the others. A typical network analysis tool is capable of being installed on any one of these nodes and measuring the performance between it and all the others. So if you installed a network analyis tool on A, you can see the performance between A and any of the others, but not between B and C. etc. Our GUI would allow the user to indicate which connections between systems are of interest. For example a and b may both send request to c. c in turn may send some requests to d, and some to e, e may send them to f. Physically any node can communicate with any other, but in any given network, only certain paths are likely to be of interest. Our GUI would provide the user with a way ot specify all nodes, and connect the ones that the user wants to analyze the performance between. Further this GUI would be a way to present the results of the analysis. A user could click on a network connection to see the analysis of that path. Remember that this GUI does not represent the actual connections between nodes, but rather a logical flow that an aplication may utilize. Now the second basic function comes into play. Typically a network analysis tool is installeed on a system, or possibly a sniffer is connected into the network. It then analyzes the network from that perspective. The one we expect to build upon issues sophisticated PINGs, and its technique is already patented by IBM. But in an N tiered network, you need to install the analysis tool on a tier, do the analysis, and then repeat this for each tier/node etc. Instead we will have a script, and use a remote execution capability (like REXEC). Using the rexec, teh tool will go to one node, and analyze the performance of a link form that node to the next. Then go to the next node and analyze the performance from that node to the next, until it has analyzed the performance of all the links that were identified by the user as being of interest. It will collect the data and return it to the GUI where it can be viewed by the user.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 1

Network performance analysis through recursive remote execution

   Current network analysis tools do a good job of measuring network performance between two points. But that makes analyzing a network a very tedious process. There are two basic aspects to this design that work together to provide the funciton that we need. The first basic function is a GUI based upon a Network diagram (or we might just stage the function in as a hierarchy first) of the network. The second basic function is a "recursive crawling" analysis program.

We are aware that some current network analysis tools give a GUI that provides a view of the network. But the tools that we have seen all show the network nodes from the point of view of the analysis tool. In our design, the GUI will show the network from a perspective of what connections are of interest. Not necessarily the physical network. For example, in a LAN of 6 nodes (a, b, c, d, e, f) all nodes may be attached in (token) ring, or switched. Logically each one can connect to all of the others. A typical network analysis tool is capable of being installed on any one of these nodes and measuring the performance between it and all the others. So if you installed a network analyis tool on A, you can see the performance between A and any of the others, but not between B and C. etc.

Our GUI would allow the user to indicate which connections between systems are of interest. For example a and b may both send request to c. c in turn may send some requests to d, and some to e, e may send them to f. Physically any node can communicate with any other, but in any given network, only certain paths are likely to be of interest. Our GUI would provide the user with a way ot spec...