GINI Roadmap
The GINI project started in 2004. It has been revised many times. It is highly usable now. However, many changes can be made to further improve it. This roadmap outlines the improvements planned ahead for GINI. If you are interested in implementing specific features in GINI, please read on.
GINI version 2.1
Highlights: Improve the gBuilder interface (performance and palette tuning issues), incorporate UDP, TCP in gRouter, better (multiple) queue management (remove synchronization bottlenecks), better installation scripts (close to one-step install for all operating systems), GINI on simple cloud, link state in gRouter, get WFQ working, host side NAT setup for Internetworking GINI. Improved documentation, display actual hostnames on gBuilder.
Details:
- Create client only installs for Windows and MacOS, Full installs for Linux, Simple Cloud installs for Linux. We could have GINI installer that is menu driven and interacts with the user and installs the most appropriate version depending on the use. The GINI installer will also setup the connection to the backend when client installations are created. IMPORTANT: Installers should do a complete job including setting up path variables.
- Simple GINI on the cloud (cluster) support. This will deploy GINI on a network of machines (normally found in university labs). We will only support Linux machines in the cloud. The cloud will have a single entry point through which the resources will be allocated to the users.
- Improve the sluggishness of the pyQt based gBuilder interface. The palette problems that create dark regions in the interface should be fixed as well.
- gRouter gets UDP and TCP. These should be properly debugged. Queuing and filtering should be enhanced and the usage should be documented. An initial API should be created for programming the gRouter.
- Enhance gRouter to support link state changes. Link failures should be detected by the gRouter.
- Debug and test the WFQ implementation.
- NAT setup at the host (with tap0) interface should be automated for connecting GINI networks to the Internet.
- Initial programming how-to for gRouter.
- Actual hostnames insteal of UML_# or Router_# on gBuilder display. Ideally this should be set inside the router or UML as well. Can this be done for the UMLs?
GINI version 2.2
Highlights: Cisco IOS CLI personality for Grouter CLI, well defined API for programming the gRouter, enhanced filtering and queuing schemes in gRouter, GINI on the Cloud, new subnet mask representation in gBuilder, LANs with multiple switches, display switch state tables (self learned), simple scripting (this is to setup a boot init script for the routers and machines).
GINI version 2.3
Highlights: wireless GINI with multiple wireless device support, wireless and wired networks, cyber-physical networks, API for programming wireless networks, VLAN support in switches.
GINI version 3.0 and Beyond
Highlights: Standalone backend daemons, discovery protocol, REST interfaces, server side scripting for work automation, initial design of GINI components.Details:
- Define a lightweight (REST style) interface for the GINI backend that can be used for all control purposes. We might still need to have frontend backend communications outside this interface to allow for wireshark and other visualization programs to run on the frontend machine. Forcing such legacy programs to operate through a REST style interface is unnecessary and can be very inefficient.
- Make the backend a standalone daemon that will remain running after the frontend is closed. This is specified when the backend was started - to remain active after detaching from the frontend. With this facility, the frontend can reconnect to an already running backend.
- Make the backends discoverable. That is a backend should publish itself on a directory server that is queried by other instances.
- Define a GINI component (a backend instance representing a running network is one example component). Once the GINI component definition is in place, discovery, access, and control of such components can be easy. The GINI component can start with version 3.0 and can be solidified in future versions. The GINI components should facilitate multiple users to interact (i.e., different network instances created and managed by different users interconnect) through GINI. Some of the components can be physical network elements and others can be virtual. They should seamlessly interoperate.