AppSwitch: Network Switching with Ada from Linux
Managing network performance is like keeping an ant colony orderly: the network has its own criteria for what to do next, the logic behind which humans often cannot fathom. The challenge is actually even more impossible, for in nature, ant colonies consist of the same species. In networks-as-ant-colonies, the database transmissions and e-mails are all different species. Some are compatible, some not. Most are friendly, some hostile, a few the equivalent of anti-personnel mines.
In order to control data communication networks, Top Layer Networks, a new company located in Westborough, Mass., developed the AppSwitch. The software automatically sorts network traffic according to both a user's priorities and the application that is generating the messages. It penetrates up to Layer 7 of an e-mail's headers, for example, which can mean translating the code of seven different “species” of applications and priorities.
The prototype for the AppSwitch 2000 was written on top of a Red Hat 5.1 Linux system. The Top Layer executives assessed Linux as too rich for the application, however, and chose to program the fielded system in Ada95. The GNAT compiler from Ada Core Technologies (ACT) allowed a seamless and fluid transition from Linux to an Ada95 system. The New York City company's stable of Ada compilers is all open-source software and available at http://www.gnat.com/.
Linux was chosen as the prototype platform OS because ACT targeted a compiler to it. Also, the Top Layer software engineers are familiar with UNIX-like operating systems. The operating system for the Back Engine of the AppSwitch is a modified version of the GNAT runtime system. As part of its modification, Top Layer also created an OS kernel that supports a POSIX interface, which Linux also supports.
After the simulator proved feasible, Ada95 was used for 90 percent of the AppSwitch's code, with the remaining ten percent being low-level commands implemented in C and assembly. Top Layer still uses Linux as the “front-end” console, i.e., the gateway between the AppSwitch and the software engineers' workstations as they further develop and test the application's next release. A new AppSwitch 2500 and 3000 are expected in fall 1999 and winter 2000.
Does building a network in Ada, a field which C dominates, make sense? Top Layer evaluated their options and decided “yes”.
First, the AppSwitch software is expected to have a long lifetime. The programming language must be portable among different target machines and generations of target machines, including those not yet invented. In other words, it must be a national and international standard, as Ada is. Yet it must not make their users or themselves hostages to one target or compiler. Again, Ada meets that need.
The Ada standard is tweaked through the following bureaucracy. The ISO's Working Group 9 responds to software development tool vendors' comments and arguments about the standard's interpretations of Ada. If the WG 9 votes on the side of the vendor, the change is reflected in a Validation Test Suite. If a compiler passes the majority of the tests, it receives a certification from the Ada Resource Association (ARA), which is an organization of software development tool vendors who cover over 90 percent of the Ada market. When an developer buys an ARA “Certified Ada” compiler, she knows the compiler has been tested to interpret “standard” Ada. The interpretations have been agreed upon internationally.
Top Layer's second criterion in selecting a language was that the software must work right the first time and continue to execute in the presence of faults and software reconfiguration. The company judged Ada to have the best combination of language features for the two requirements of high reliability and portability, including strong typing, object-oriented features, multitasking and exception handling.
Ada is not “another damned acronym”. The language is named after the first published computer programmer, the Countess of Lovelace, Ada Byron King. Yes, that Byron; she was the poet's only legitimate daughter. A mathematician, she worked with Charles Babbage on the Difference Engine, and prophesied the computer's many applications, such as writing music, calculating variables, etc., as well as the potential of reusing code, which the Ada language was designed to fulfill.
GNAT was chosen as the tool chain because it is based on GCC and GCC is targeted to the ARC processor. The Ada tools are hosted on Solaris and Linux and targeted to the Motorola MPC 860, the ARC and x86.
The AppSwitch is a multiprocessor system. The software architecture is designed to take advantage of Ada95's distributed system features as the implementations mature. The AppSwitch analyzes network application traffic and enforces quality of service policies automatically, i.e., with no human intervention and no changes to PCs or servers. The AppSwitch coordinates both hardware, to examine and direct traffic at wire speed, and software, to guide the switching and the network's performance. Clients' business objectives decide the AppSwitch's policy criteria, a process that occurs with quotidian emergencies and projects, yet proves evolutionary as the business's function and size change. AppSwitch immediately benefits a business by enforcing criteria that allow the network to resemble a human messaging system more than an ant's.
With its integrated hardware and software architecture, the AppSwitch lets a network administrator monitor and understand all the elements of the network. The administrator adapts the network to changes through the AppSwitch's web-based graphical user interface.
The hardware and software components that constitute flow classification technology are at the core of the AppSwitch. With this technology, the AppSwitch goes deeply into the incoming packets, up to the application's Layer 7 headers, to determine the packets' source, type and destination addresses. The pre-configured Application Definition Library (ADL) supports the AppSwitch flow classification. The ADL is built into every switch and holds the rules for flow classification and prioritization.
When the first packets of a flow arrive, the AppSwitch uses a connection-setup-process subarchitecture to select the appropriate “tailored” profile in the ADL. It also establishes pertinent information on the new flow, which is captured in the session database. After that, the AppSwitch routes remaining packets in the flow through the coordination of the session data and the selected profile. The state data captured by each flow in the session database can intelligently adjust the quality of the service as needed to upgrade or downgrade priority. On the output side, thousands of queues are available to expand the number of flows and priorities among those flows.
The AppSwitch works behind a router or in a LAN environment. Incoming packets are subjected to proprietary “triage” by the media-access-control function (MOM) components to broadly categorize the packets. It also puts the packets into a canonical form that is data-link-independent. From there, the “categorized” packets flow over the TopWire to the Forwarding Engine (FE Chip + QM Chip) where the application control is performed.
Ada was applied in an uncomplicated manner to both the Forwarding Engine architecture and the Background Engine. While meeting deadlines is important, the AppSwitch is not strictly a hard real-time application. Top Layer's engineers eliminated some restrictions on the software from a traditional real-time application. They therefore permitted greater flexibility in the software architecture to accommodate the dynamic nature of data communications.
Ada contributed to Top Layer's success in meeting an aggressive nine-month development schedule. That is fortunate, for the decision to program in Ada met with resistance from the predominantly C shop. The engineers' learning curve steepened and grew icicles as they wondered how “Ada” will read to future employers looking for the letter “C”.
Linux users everywhere will sympathize with management's challenge to make Ada not only palatable but also preferable to the reigning zeitgeist of Microsoft, which includes C and C++ as well as the Windows OS.
They succeeded. Once Top Layer corporate executives decided Ada was the best choice, they stuck with it. Their commitment to Ada was top down and unwavering. They hired a full-time Ada expert, Mike Kamrad, to provide intensive internal training in and advocacy of Ada. The result was a personal education for all the software engineers. Finally, Top Layer took extra steps to make Ada work technically on the target systems, thereby providing a trusted and well-performing tool chain and avoiding further resistance and frustration to learning.
Like the AppSwitch itself, the engineers found that Ada speaks a sensitive, sophisticated and robust language. Ada enabled Top Layer to create an Esperanto for network administrators. The AppSwitch allows them to interpret the e-mails and transmissions' unique signals into the international and human-friendly language of graphical interfaces. The goal is to direct the multitudes of unique ant-like bytes into the tunnel-like channels that will most efficiently build and strengthen a business. The AppSwitch makes that goal possible, but only because Top Layer, in using Linux and Ada, bushwhacked their way off the worn trails of network switching systems.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Control Your Linux Desktop with D-Bus
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide