gdist instantiates all switches in daemon mode, one for every UML interface and one for every Router interface. This allows these components to communicate with the outside world. All other components (UMLs and Routers) are instantiated in detached mode using the screen utility. The screen(1) command can be used appropriately to bring these components back into interactive mode. Note that gdist doesn't allow the topology to have switches. The switches mentioned here are automatically added by gdist so that the components can interact with the outside world. If there are switches specified in the topology, an error is thrown as connectivity constraints can't be properly calculated if switches are present.
gdist leaves a file named gini_dist in the directory from where it is launched. The latest command line options used are stored in this file, so that the command can be re-issued quickly without re-specifying the options.
When used to terminate a GINI micro Internet instance, gdist connects via SSH into all specified IPs in the IPFile and performs a kill-9-1 command. This is why it is unsafe to specify the machine you are working at right now as a IP argument. When you undistribute the network, it will kill-9-1 your machine as well. Upon termination, all the generated files and scripts are deleted. Folders for each GINI component are, by default, deleted from the remote IP directory provided in the IPFile, leaving the directory empty of any GINI folders. If you want to keep these directories, then undistribute with the -k option.
gdist will kill any process linked to your username on all IP addresses provided in the IPFile. DO NOT SPECIFY YOUR MACHINE WITHOUT SAVING YOUR WORK!!!
username@ip-address:/full/path/to/dir
You can specify as many IP-DIR tuples as you like, one per line. If you are using authorized SSH heys you need not put your username, although it is recommended. The remote IP address and the directory must be separated with a colon, as per the SCP protocol. No trailing slash is put on the directory but a starting slash must be there as it is the absolute path. You must also make sure the directory exists and is accessible with the proper permissions so that gdist can create the GINI subdirectory and manipulate it.
So, for example, an IPFile entry may look like this:
reehan@192.168.1.1:/home/user/reehan/gini-work
There are no assumptions made on the remote IPs provided. For all gdist knows is that the remote machines are linearly connected. To distribute your components in a smart fashion so that you can have an optimized network topology, note that the first "m" IPs specified in the IPFile get assigned to the "m" routers and the following "n" remote IPs specified will get assigned to the "n" UMLs. gdist does a loop on the IPFile and will let you know if there are more GINI components than specified IPs. If you don't specify enough IPs, more than one GINI component will be alive on a single remote machine. This is okay since each component will have its own subdirectory and instantiation. It is useless to have the same remote IP listed more than once but with different working directories. Because the for-loop iterates over the list of IPs, it will always find the first listed IP match and use the directory specified for that and will never use the second or subsequent listed matches.
Everything gdist does will go under a working directory called GINI, automatically created so that you don't pollute the directory you specified. This is done to keep your file structure nice and neat. Even the directories are labelled with information. For example, a switch that was created for UML_1 on eth0 will be configured in a directory with the path:
provided_directory_in_IPFile/GINI/UML_1_Switch_eth0
or more generically:
provided_directory_in_IPFile/GINI/[device_name]_Switch_[device_interface]).
All other components are created in a directory named with the component's name, under:
provided_path_in_IPFile/GINI/[component_name]
-y [xml-file]
-x [xml-file]
-s switch-dir
-r route-dir
-u uml-dir
-b bin-dir
-k
With the -x option, by default, gdist refuses to distribute a new GINI instance, if another instance is already active. This default check can be bypassed with -k option and multiple GINI instances can be created simultaneously. Generally using this option is not advisable. If you use it, use it with care: a new GINI instance can overwrite the directories of the existing GINI components, if the names of the components in the different instances match. A check is performed on every remote machine to make sure no GINI component is alive there. A print out of the remote machines that need to be cleaned is done.
With the -y option, gdist will keep the directories and configuration files when a GINI instance is undistributed. But it won't keep the instances. The instances still get killed but the folders, .conf files, etc... are kept so that you can view them.
We are also looking into a way to allow switches into the topology, so that gdist doesn't complain. We will let you know of any updates.
Report other bugs to reehan.shaikh@cs.mcgill.ca
It was then reincarnated and extended in Python by Balasubramaneyam Maniymaran.
gdist is adapted from gloader and is written in Python by Reehan Shaikh.