November 5, 2011 at 15:28UNIX-way and computer network architecture job generator
Last winter, one wonderful event happened at our beloved department - the computer network design course was reorganized, as a result of which instead of one semester of practical classes, two semesters of laboratory classes were formed. On the one hand, both changes - both qualitative and quantitative - meant that students would get more time to master the subject, and also classes would be individual rather than group - to think, it is likely that everyone will have to, and not the “core” of the group of four -five people. On the other hand, this meant that it was necessary to develop these very individual tasks, so that they were all different from each other.
It was then that the idea arose to write an automatic task generator. About the generator of one of the tasks I will tell below.
The task was to build and configure the necessary network configuration in Cisco Packet Tracer. Accordingly, the following requirements were imposed on the task builder:
The generator itself consists of a generator of the network graph itself, a generator of disjoint address ranges, and a visualization generator.
To write the network graph and range generators, it was decided to use the Tcl language, which is now quite undeservedly enjoying relatively little popularity. We did visualization using Graphviz , and the final document was formed using LaTeX.
The network graph, as is easy to see, can be easily represented as a tree structure in which each network node can be mentioned more than once. The question arose: how to effectively store the tree structure itself? After several attempts to use different approaches, a choice was made in favor of nested dictionaries.
As you know, in Tcl, almost any object can be represented as a text string. Dictionaries are no exception. A dictionary in Tcl is a list containing key-value pairs, and any list, in turn, can be written as a string in which list items are separated by spaces. This structure is a bit like JSON, but has a slightly simpler structure.
Thus, use the dictionary as a list of connections between network nodes: the key is the number of the node, and the value is a list of nodes with which this node is associated. Each of the elements, in turn, is also a dictionary, which by default contains one element, in which the key is the node number, and the value is empty. The above can be illustrated as follows: The
corresponding dictionary will look like this:
The advantage of this structure is the ability to select on the way to the element: call
Actually, having the means of storing the network structure, building the network itself was no longer a problem - in accordance with the testimony of the random number generator, new nodes were added while conditions were checked.
By the way, about the generators. In a first approximation, the script gave very strange results, after which I decided to look at the results of several calls to the random number generator. When I got something like:
Another advantage of the chosen graph storage method was the simplicity of checking for the presence of all nodes in the network - all brackets were removed from the text representation of the graph, as a result of which the graph turned into a flat list, after which by removing duplicate elements (
When the network is generated, the same Tcl script saves the graph in Graphviz dot format, which is converted to EPS, suitable for feeding LaTeX. When the graph is displayed in dot, the font CMR12 is explicitly set so that the final document does not have a variety of font headsets. Here, however, there is one annoying surprise: fonts created in this way, of course, will not be embedded in fonts, but during the final assembly of the document, only those characters that are used by LaTeX will be included in the output file. Therefore, for the correct display of the inscriptions, it was necessary to add the letter “N” standing behind the margins of the paper in this LaTeX source.
A traditional “conveyor” of LaTeX, dvips and ps2pdf is used to assemble the document.
The orchestra conducts a small Makefile that invokes scripts as well as the above tools.
After several minutes of operation, the generator produced a two megabyte PDF containing 1000 jobs, one job per page. The tasks looked something like this:
It was assumed that the task number would correspond to the last digit of the group number and the student number in the group. In practice, there were more than half as many groups as there were hundreds of tasks, and there were far from 100 students in each group, so students would not have shortages of tasks in the next couple of years.
In addition, a assignment page was attached to the assignments, as well as a desire to understand why dynamic routing is needed :)
The reaction of the students to the thousand-page PDF was approximately: “Uh ?!” One of the students' proposals amused me: “And if I write a program that parses the network configuration from this PDF and then generates the configuration for Cisco, will it be counted?”
Generator, which I described above, it is an excellent example of how, by connecting various programs to each other, to get the desired result without the painful invention of bicycles. Of course, I had to cycle a bit, but it would have been much worse if I hadn’t at my disposal such wonderful tools as TeXLive, Graphviz, as well as my favorite scripting languages.
In general, this is all I wanted to tell. Thanks for attention.
PS Those interested can find the source codes of the project at:http://bitbucket.org/andrew_shadoura/netgen .
It was then that the idea arose to write an automatic task generator. About the generator of one of the tasks I will tell below.
The task was to build and configure the necessary network configuration in Cisco Packet Tracer. Accordingly, the following requirements were imposed on the task builder:
- the maximum number of nodes in the network is 8;
- the maximum number of links leaving the node is 3;
- the maximum number of links on the network is 12.
A little boring technical details
The generator itself consists of a generator of the network graph itself, a generator of disjoint address ranges, and a visualization generator.
To write the network graph and range generators, it was decided to use the Tcl language, which is now quite undeservedly enjoying relatively little popularity. We did visualization using Graphviz , and the final document was formed using LaTeX.
The network graph, as is easy to see, can be easily represented as a tree structure in which each network node can be mentioned more than once. The question arose: how to effectively store the tree structure itself? After several attempts to use different approaches, a choice was made in favor of nested dictionaries.
As you know, in Tcl, almost any object can be represented as a text string. Dictionaries are no exception. A dictionary in Tcl is a list containing key-value pairs, and any list, in turn, can be written as a string in which list items are separated by spaces. This structure is a bit like JSON, but has a slightly simpler structure.
Thus, use the dictionary as a list of connections between network nodes: the key is the number of the node, and the value is a list of nodes with which this node is associated. Each of the elements, in turn, is also a dictionary, which by default contains one element, in which the key is the node number, and the value is empty. The above can be illustrated as follows: The
corresponding dictionary will look like this:
0 {
12
3 4
5 6
7 {
8 2
3 {}
}
}The advantage of this structure is the ability to select on the way to the element: call
[dict get $tree 0 7 8]Actually, having the means of storing the network structure, building the network itself was no longer a problem - in accordance with the testimony of the random number generator, new nodes were added while conditions were checked.
By the way, about the generators. In a first approximation, the script gave very strange results, after which I decided to look at the results of several calls to the random number generator. When I got something like:
2 9 0 1 5 7 7 7 4 7 7 7...I had to slightly modify the procedure getrandomso that it did not return the same values in a row. Probably experts on random number generators will throw me something, but this approach in this application has paid off.Another advantage of the chosen graph storage method was the simplicity of checking for the presence of all nodes in the network - all brackets were removed from the text representation of the graph, as a result of which the graph turned into a flat list, after which by removing duplicate elements (
[lsort -uniq]) it is easy to get a list of all graph nodes from it .When the network is generated, the same Tcl script saves the graph in Graphviz dot format, which is converted to EPS, suitable for feeding LaTeX. When the graph is displayed in dot, the font CMR12 is explicitly set so that the final document does not have a variety of font headsets. Here, however, there is one annoying surprise: fonts created in this way, of course, will not be embedded in fonts, but during the final assembly of the document, only those characters that are used by LaTeX will be included in the output file. Therefore, for the correct display of the inscriptions, it was necessary to add the letter “N” standing behind the margins of the paper in this LaTeX source.
A traditional “conveyor” of LaTeX, dvips and ps2pdf is used to assemble the document.
The orchestra conducts a small Makefile that invokes scripts as well as the above tools.
What happened as a result
After several minutes of operation, the generator produced a two megabyte PDF containing 1000 jobs, one job per page. The tasks looked something like this:
It was assumed that the task number would correspond to the last digit of the group number and the student number in the group. In practice, there were more than half as many groups as there were hundreds of tasks, and there were far from 100 students in each group, so students would not have shortages of tasks in the next couple of years.
In addition, a assignment page was attached to the assignments, as well as a desire to understand why dynamic routing is needed :)
The reaction of the students to the thousand-page PDF was approximately: “Uh ?!” One of the students' proposals amused me: “And if I write a program that parses the network configuration from this PDF and then generates the configuration for Cisco, will it be counted?”
Generator, which I described above, it is an excellent example of how, by connecting various programs to each other, to get the desired result without the painful invention of bicycles. Of course, I had to cycle a bit, but it would have been much worse if I hadn’t at my disposal such wonderful tools as TeXLive, Graphviz, as well as my favorite scripting languages.
In general, this is all I wanted to tell. Thanks for attention.
PS Those interested can find the source codes of the project at:http://bitbucket.org/andrew_shadoura/netgen .