Sniffing involves capturing, decoding, inspecting and interpreting the information inside a network packet on a TCP/IP network. The purpose is to steal information, usually user IDs, passwords, network details, credit card numbers, etc. Sniffing is generally referred to as a “passive” type of attack, wherein the attackers can be silent/invisible on the network. This makes it difficult to detect, and hence it is a dangerous type of attack.

As we already learnt over the previous months, the TCP/IP packet contains vital information required for two network interfaces to communicate with each other. It contains fields such as source and destination IP addresses, ports, sequence numbers and the protocol type. Each of these fields is crucial for various network layers to function, and especially for the Layer 7 application that makes use of the received data.

By its very nature, the TCP/IP protocol is only meant for ensuring that a packet is constructed, mounted on an Ethernet packet frame, and reliably delivered from the sender to the receiver across networks. However, it does not by default have mechanisms to ensure data security. Thus, it becomes the responsibility of the upper network layers to ensure that information in the packet is not tampered with.

To understand why hackers sniff, we need to know what they can get from the network. Figure 1 shows the OSI layers and the information a hacker can steal at each layer by successfully sniffing a network.

Figure 1. Mapping of OSI layers

The sniffing process is used by hackers either to get information directly or to map the technical details of the network in order to create a further attack. Hackers are always in favour of sniffing, because it can be done for a longer time without getting caught.

How do they ‘sniff’?

Network sniffing uses sniffer software, either open source or commercial. Broadly, there are three ways to sniff a network, as shown in Figure 2.

Figure 2. Sniffing attack vectors

It is important to remember that sniffing can range from Layer 1 through Layer 7. Talking about physical connectivity, a person (who may be an employee of the firm) who is already hooked up to the internal LAN can run tools to directly capture network traffic. Using spoofing techniques, a hacker outside the target network can intercept packets at the firewall level and steal the information. In the latest form of packet sniffing, wide usage of wireless networks has made it easy to sit near the network and penetrate it to get information.

Regardless of where the hackers are located on the network being sniffed, they use packet capturing or packet sniffer software. Modern packet sniffers are supposed to be used for troubleshooting network problems, but can be used for hacking too. Please refer to the following table, which depicts the ethical and unethical side of sniffer software.

Regarding the technical details of how sniffing is done, we need to remember that packet capturing software always runs in promiscuous mode, whereby it is capable of intercepting and storing all packets on a network. This also means that, even though the packet is not meant for the network interface on which the sniffer is running, it is captured, stored and analysed.

Sniffer software contains its own network driver and buffer memory in order to capture a large chunk of packets. Modern sniffers are capable of analysing the captured packets and converting them into sensible statistical information. Now let’s discuss a few ways of sniffing a network, to understand how hackers get what they want.

A LAN sniff

A sniffer deployed on an internal LAN can scan the entire IP range promiscuously. This helps in providing further details such as live hosts, open ports, server inventory, etc. Once a list of open ports is gathered, a port-specific vulnerability attack is possible.

A protocol sniff

This method involves sniffing data related to the network protocols being used. First, a list of protocols is created based on the captured data. This is further segregated to create special sniffers for each attack. For example, in a network sniff capture, if the ICMP protocol is not seen, it is assumed to be blocked. However, if UDP packets are seen, a separate UDP sniffer is started to capture and decipher Telnet, PPP, DNS and other related application details.

An ARP sniff

In this popular method, the hacker captures a lot of data in order to create a map of IP addresses and the associated MAC addresses. Such a map is further used to create ARP poisoning attacks, packet-spoofing attacks, or to dig into router-based vulnerabilities.

TCP session stealing

This method is a very basic form of sniffing, in which a network interface in promiscuous mode captures traffic between a source and a destination IP address. Details such as port numbers, service types, TCP sequence numbers and the data itself are of interest to hackers. Upon capturing enough packets, advanced hackers can create fabricated TCP sessions to fool the source and destination, and be the man in the middle to take over the TCP session.

Application-level sniffing

Usually, from the data packets sniffed and captured, a few intricate application details are found out for information stealing or to create further attacks. As an example, the capture file can be parsed to perform OS fingerprinting, SQL query analysis, reveal application-specific TCP port data information, etc. In another approach, creating a mere list of applications running on a server is good enough to plan an application-specific attack on it.

Web password sniffing

As the name suggests, HTTP sessions are stolen and parsed for user ID and password stealing. While the Secure Socket Layers (SSL) are incorporated for securing HTTP sessions on the network, there are numerous internal websites that still use standard but less secure encryption. It is easy to capture Base64 or Base128 packets and run a deciphering agent against it to crack the password. In modern sniffers, SSL sessions can also be captured and parsed for information, though this method is not very easy.

Detecting sniffers

As mentioned earlier, since sniffers work silently, it is very difficult to detect them on a network. There are, however, a few tricks that can provide a clue to a possible sniffer presence. There are two ways to detect a sniffer — host-based and network-based.

In host-based detection, you can use small utilities to detect if the NIC is running in a promiscuous mode on any host in a network. Since the basic requirement for a sniffer to work is to put the network interface in “read all” mode, disabling it can very effectively help shutting down stray sniffers.

In case of network-based detection, anti-sniffer software can be run to detect the presence of specific signature packets. In another approach, scripts can be run to check each network host for the presence of known sniffers, processes, etc. Modern anti-virus or anti-spyware software are capable of detecting sniffing software and disabling it.

Protection from sniffers

While the very first step should be to design a tight perimeter defense system while creating network architecture, there are a few methods that could be deployed to make the infrastructure less sniffer-prone. The following tricks help achieve that to a great extent.

Disabling promiscuous mode on network interfaces results in shutting down most sniffer software. This can be done by running an admin script as a daily job on the network, or deploying a network policy at the host level to control access to the network card configuration settings.

Using switched networks can reduce the possibility of a sniffer running on the network. Unlike in a network hub, in a switched network the packets are delivered to the destination and are not visible to all nodes — thus reducing the chances of someone sniffing it on the way. Also, for network administrators it becomes easy to detect sniffers by focusing on the switched network segments, one at a time.

Anti-sniffing tools can be used to detect the network interface mode, as well as various processes and software present on servers or network hosts. Modern intrusion-detection systems have this as an integrated feature.

IPSec encryption can be used for token-based packet security in the network infrastructure, if the data is of a confidential nature. IPSec provides data encapsulation and encryption of high standards, and is available on modern routers, firewalls and other network components. Almost all operating systems do support IPSec, and it is widely used in serious IT infrastructure. For session layer protection, SSL and TLS can be used to encrypt traffic.

Protecting FOSS systems

Let us now look at a few sniffer products, in order to learn about what is used in the FOSS world today. Linux systems use the tcpdump utility, which is an excellent built-in sniffer to capture and store TCP packets. As for third-party open source tools, Wireshark (Ethereal) is very famous due to its GUI interface, and packet-filtering and viewing capabilities. Sniffit, DSniff and Ettercap are similar utilities, but meant for different purposes. DSniff is powerful in terms of capturing SSL traffic.

FOSS systems have no built-in method to protect themselves from sniffers. The methods described above could pretty much be used for various Linux distros, to make those less vulnerable to sniffer attacks. A smart utility available on Linux distros, called AntiSniff, can be used in a script to detect network interfaces in promiscuous mode.

Network sniffing is difficult to detect because it is a passive and silent type of attack. There are methods to detect and disable sniffers, and network administrators should incorporate those into their network to protect their IT infrastructure from information loss or theft.

The Internet has become an essential part of our lives. Everybody is on the Net, surfing with different types of devices: PCs, laptops, iPads, mobile phones, etc. Each of these needs a unique IP address on the Internet, when directly connected. The present IP (Internet Protocol) addressing system, IPv4, uses a 32-bit number, represented in 4 octets — for example, 192.16.1.2.

The problem

Since IPv4 addresses are 32-bit numbers, there are only 2³², or just over four billion, possible addresses available — and they have all been allocated. On February 3, 2011, the Internet Assigned Numbers Authority (IANA), which controls the world-wide distribution of IP addresses, allocated the final pool of IPv4 address space to the five Regional Internet Registries (RIRs). This means that there are no longer any IPv4 addresses available for allocation from the IANA to the five RIRs.

So does this mean the end of the Net? Well, not really. Luckily, this problem was foreseen, and an alternative to IPv4 developed. The new addressing scheme, IPv6, uses 128-bit numbers for addresses — hence, there are 2¹²⁸ individual addresses available (approximately 3.4×10³⁸). All new IP addresses from now will be IPv6.

What, then, is the “next Y2K”? The problem is that IPv4 is NOT directly compatible with IPv6. This means that devices connected via IPv4 (which make up most of the existing Internet) cannot communicate directly with systems connected using IPv6 (and vice versa). If your website is on an IPv4 connection, it won’t get traffic from IPv6 sites/users and the reverse is also true. Getting traffic is essential to any business on the Net; nobody can afford to lose IPv6 users. Hence, to continue offering customers the same level of service, every organisation needs to be planning IPv6 deployment now.

The IPv6 compliance scenario

All major US government federal agencies have migrated their infrastructure (network backbones) to using IPv6, and all agency networks were enabled to interface with this infrastructure with effect from June 2008. The US government’s Chief Information Officers require that all new IT procurements be IPv6 compliant. An IPv6-compliant product or system must be able to receive, process, and transmit or forward (as appropriate) IPv6 packets, and should interoperate with other systems and protocols in both IPv4 and IPv6 modes of operation.

The US Defense Department, with its $30 billion budget, has been buying only IPv6-compliant networking gear since October 2003, and had already achieved full IPv6 compliance in 2008. ICANN, the company that handles the domain names and IP addresses for the world, has also enabled its servers to be IPv6-compliant. There has been significant IPv6 adoption in Japan and Korea, with production networks and consumers paying for IPv6-based services. China is spending millions developing a new backbone network that is reportedly going to be IPv6. The European Union (EU) has also heavily financed R&D in IPv6 backbone networks and innovative services that leverage many of the beneficial features of IPv6.

On June 8, 2011, Google, Facebook, Yahoo!, Akamai and Limelight Networks are among some major organisations that will offer their content over IPv6 for a 24-hour “test flight”. The goal of this Test Flight Day is to motivate organisations across the industry — Internet service providers, hardware manufacturers, operating system vendors and Web companies — to prepare their services for IPv6, to ensure a successful transition as IPv4 addresses run out.

India will start using IPv6 from March 2012, according to a new roadmap released by the Indian government. All telecom companies and ISPs will have to be IPv6-compliant by the end of next year, and offer IPv6 services thereafter. Federal and state government ministries, departments and public sector companies will switch over to IPv6 services by March 2012.

So what do I do?

It is imperative for any organisation to be IPv6-ready, in order to remain competitive. The first step is to assess where your organisation stands in relation to IPv6. If your website is hosted by an Internet Service Provider (ISP), ask its customer support personnel the following questions:

• Do you currently provide IPv6 connectivity?
• If not, when do you plan to deploy IPv6 on your customer networks? What is your deployment timeline?
• When will my website be available over IPv6? What extra cost will that entail?
• Do you provide customers with IPv6-compatible modems, or other devices necessary for connecting over IPv6?
• Why have you not provided us any information on IPv6 that would help us put in place all that’s needed from our side, to be ready for IPv6 compliance?

Next, carry out an audit of your entire IT infrastructure, and identify the hardware/software that needs to be changed or upgraded. For your hardware (routers, servers, etc), get in touch with the OEM or vendor to check for IPv6 compliance. Ensure that all the equipment is dual stacked (running both IPv4 and IPv6). If the hardware does not support IPv6, find out from the OEM whether a replacement is required, or if an upgrade/patch will suffice.

For software purchased from a third party, get in touch with the provider to check if the product is already IPv6 compatible, or if there’s an upgrade available. If no IPv6 upgrade is available, look for an alternative software source. Any software that has been developed in-house may have to be rewritten. Identify and change all hard-coded IPv4 addressees in software code to IPv6. Any application that directly uses network sockets or other network-related programming might have to be rewritten. Most operating systems are IPv6 compatible — IPv6 support is built in, and you only need to activate it. However, identify any legacy systems running an OS without IPv6 support, and either replace them, or patch/upgrade the OS.

I use FOSS; am I affected?

IPv6 migration is an issue that affects everyone. It is not restricted to only particular hardware or software. The problem is independent of the technology or software you use, as it stems from a core flaw in the TCP/IP addressing scheme. So yes, people using open source operating systems and applications could also be affected.

Linux and IPv6

The first IPv6-related network code was added to the Linux kernel 2.1.8 in November 1996 by Pedro Roque. In most Linux configurations these days, IPv6 is active by default, and the required IPv6 kernel modules are loaded automatically. To check whether your current running kernel supports IPv6, look in your /proc filesystem for the pseudo-file /proc/net/if_inet6. If this entry is not present, you can try to load the IPv6 module by executing modprobe ipv6. If successful, this module should be listed by the following command:

lsmod | grep -w 'ipv6' && echo "IPv6 module successfully loaded"

It is also possible to automatically load the IPv6 module on demand. You have to add the following line to the kernel module-loader configuration file, which is normally /etc/modules.conf or /etc/conf.modules:

alias net-pf-10 ipv6 # automatically load IPv6 module on demand

If your kernel has no IPv6 support, then you can try one of the following options:

• Update your Linux distribution to a current one that supports IPv6 out-of-the-box.
• Compile a new vanilla kernel.
• Recompile kernel sources given by your Linux distribution.
• Compile a kernel with third-party IPv6 extensions.

However, it is pertinent to point out that IPv6 support in the kernel and the other basic packages is pretty average in terms of performance, and does not conform to all drafts and RFCs (request for comments). Most people tend to switch off the IPv6-compliance feature, as it makes the DNS queries kind of slow.

To overcome this, you can make use of the USAGI (Universal Playground for IPv6) kit, which contains an enhanced IPv6-enabled version of both the latest 2.6.x Linux kernel, and the most important networking software packages for Linux. USAGI is a project run by volunteers from various organisations, and aims to develop a production-quality IPv6 protocol stack and IPsec for Linux. Based in Japan, USAGI teams up with other such projects like the WIDE Project, the KAME Project and TAHI, to implement all absent or obsolete IPv6 support in Linux. You can download the latest release of the USAGI kit from here.

Apache and IPv6

The Apache HTTP server supports IPv6 on most platforms, allowing Apache to allocate IPv6 sockets and handle requests sent over IPv6. However, to allow the IPv6 socket to handle both IPv4 and IPv6 connections, you will need to tweak the configuration parameter and use generic Listen directives. To verify that Apache is working in dual-stack mode (supporting both IPv4 and IPv6), use the netstat command.

The writing is on the wall. With IPv4 addresses having been exhausted, the time, cost and complexity of operating a stable and growing Internet will rise significantly, unless IPv6 deployment is well under way. So hurry and make your organisation IPv6-ready, now!

A virtual machine (or VM) is an isolated, self-contained implementation that abstracts hardware resources. Typically, it simulates an actual physical machine capable of executing instruction sets. Broadly, VMs are classified based on how they work and their  functionality. There are process VMs, which support the execution of a single process/program (e.g., Java, .NET), and system VMs, which support execution of a complete operating system (e.g., VirtualBox, VMWare).

How does a VM work?

In general, a VM is an interpreter for an instruction-set. The fundamental task of a compute machine is to carry out an operation. An operation is performed with the execution of a set of instructions. A basic instruction goes through the following cycle of events:

• Instruction fetch, where an instruction is fetched from memory.
• Decoding, which determines the type of the instruction — the opcode, or the operation it is supposed to perform. Additionally, decoding may also involve fetching operand(s) from memory.
• Execute. The decoded instruction is then executed; the operation is performed on the operands.
• Storing the result in the mentioned register.

Which VM implementations to choose

Mainly, VMs are implemented in one of two ways — a register-based VM, or a stack-based VM. The register-based VM computation model assumes registers as the memory, and operands are accessed with explicit addresses coded in an instruction. In the stack-based VM model, memory takes the form of a Last-In-First-Out (LIFO) stack. Every operation boils down to a stack PUSH/POP or STORE/LOAD. These instructions do not need explicit operand addresses, because the operand is always available with the stack pointer (top-of-stack). Examples are Microsoft .NET and the JVM.

Traditionally, when it came to choosing the VM architecture, people preferred stack-based machines, rather than the register-based architecture prevalent in most real processors. The main reason for this choice was the simplicity of the compiler, which emanates from the fact that stack instructions are small, and have implicit addressing. The basic criteria for choosing a particular VM implementation is the code size of the machine implementation (the smaller the better); and machine efficiency — which is measured in terms of the number of instructions needed to carry out an operation.

Implementation-wise, instructions for a stack-based VM are shorter (since it’ll have only POP/PUSH instructions) and are hence faster to fetch. A register-based VM has long instructions, and usually a quadruple of {opcode, result, operand1, operand2}. However, the advantage of the stack-based VM diminishes in terms of the number of instructions needed to perform an operation. A given task can often be expressed in fewer register-based VM instructions than what is required for a stack VM. For example, an addition operation “a = b + c” would need the following instructions for a stack VM:

I1: LOAD C
I2: LOAD B
I3: ADD
I4: STORE A

The equivalent operation in a register VM can be expressed in a single instruction:

I1 "add, a, b, c"

The fewer the instructions, the smaller the number of instruction dispatches needed. (Instruction dispatch involves fetching/reading the instruction from memory, and jumping to the corresponding segment of VM code that implements the VM instruction.) Instruction dispatch is an expensive and often unpredictable operation, because in implementation it is essentially a “switch-case”, and hence a hard-to-predict indirect branch, unlike an “if-else” condition.

There is a cost involved in the operand access too. In stack VMs, operands are accessed relative to the stack pointer, and hence explicit addressing for operands is not required. On the contrary, register VMs need to provide the location of all operands, by specifying the registers that carry those operands.

Having all operands in the instruction has its benefits; the execution is faster compared to the stack VM, which needs a small calculation to find out the operand, while register VMs just read the registers.
Also, a stack VM might consume more memory cycles, since it uses a set of registers to simulate a stack. Besides, temporary values often spill out into the main memory, adding more memory cache cycles.

In register VMs, temporary values usually remain in registers. Stack VMs are unable to use a few optimisations too. For example, in the case of common sub-expressions, which are recalculated each time they appear in the code, a register VM can calculate an expression once, and keep that in a register for all future references.

These reasons made a register VM model the preferred choice of implementation for the Dalvik VM, where quick execution is the foremost requirement.

The Android OS stack

Android is a complete software stack that comprises the Linux kernel, middleware and a few useful applications. It is developed, promoted, and maintained by Google. Its software stack is shown in Figure 1.

Figure 1: Android OS stack

The top layer comprises portable user applications, programmed in Java. These rely on the next layer, which exports a rich set of Java APIs, and provides a set of services and a system to facilitate applications, e.g., the content manager, resource manager, view services, etc.

The next layer comprises C/C++ system libraries and the Android runtime. The common set of system libraries includes:

• System C library (libc)
• Media library
• SQLite (database engine)
• SGL (to support 2-D graphics)

The Android runtime is a combination of the Dalvik VM and Java core libraries.

The Linux kernel is the last layer in the software stack, and provides an abstraction of the underlying hardware, also taking care of networking, process and memory management.

Dalvik VM

Dalvik VM is Google’s implementation of the Java VM, targeted to run on mobile devices. Dalvik is a process VM; each Android application runs in its own Linux process. Every process on Android has its own instance of the Dalvik VM, which is created along with the process, and destroyed during process termination.

“init” is the parent process for all Android processes. During startup (see Figure 2), in addition to a handful of daemons, “init” forks a process named zygote, which loads and initialises an instance of the Dalvik VM and core services. zygote then creates a read socket, and runs a select loop on it. When we run an application, a message is sent to zygote, which forks, and contacts the Android Activity manager service to run the application’s Java class. Thus, all processes share a copy of DVM, created by the Zygote process, and avoid keeping duplicate pages of DVM.

Figure 2: The Android runtime

Actually, pages for DVM are COW (copy-on-write) among processes; as soon as a process writes to a shared, read-only page, that page becomes local to the process.

Why a process VM?

This design has many benefits compared to a single system VM instance that serves all processes in the system. If the VM crashes, the whole system would crash, killing all processes. In Android, this problem has been narrowed down to the granularity of a single process.

VM internal details

The Dalvik VM accepts Dalvik byte-code (*.dex files) as input, instead of the Java byte-code expected by a JVM. The *.dex files are created by the dxtool, which is part of the Android system (see Figure 3). This tool takes Java class files created by the Java compiler as the input.

Figure 3: The compilation flow of a Java application on Android

How is a Dalvik-like register VM implemented?

To answer that, let’s implement a register VM in C — myvm.c:

/*
 * myvm.c
 */
#include "stdio.h"

#define NUM_REGS 4
#define TRUE    1
#define FALSE   0
#define INVALID -1

enum opCodes {
    HALT  = 0x0,
    LOAD  = 0x1,
    ADD   = 0x2,
};

/*
 * Register set of the VM
 */
int regs[NUM_REGS];

/*
 * VM specific data for an instruction
 */
struct VMData_ {
  int reg0;
  int reg1;
  int reg2;
  int reg3;
  int op;
  int scal;
};
typedef struct VMData_ VMData;

int  fetch();
void decode(int instruction, VMData *data);
void execute(VMData *data);
void run();

/*
 * Addressing Modes:
 * - Registers used as r0, r1,..rn.
 * - Scalar/ Constant (immediate) values represented as #123
 * - Memory addresses begin with @4556
 */

/*
 * Instruction set:
 * - Load an immediate number (a constant) into a register
 * - Perform an arithmetic sum of two registers (in effect,
 *   adding two numbers)
 * - Halt the machine
 *
 * LOAD reg0 #100
 * LOAD reg1 #200
 * ADD reg2 reg1 reg0  // 'reg2' is destination register
 * HALT
 */

/*
 * Instruction codes:
 * Since we have very small number of instructions, we can have
 * instructions that have following structure:
 * - 16-bit instructions
 *
 * Operands get 8-bits, so range of number supported by our VM
 * will be 0-255.
 * The operands gets place from LSB bit position
 * |7|6|5|4|3|2|1|0|
 *
 * Register number can we encoded in 4-bits
 * |11|10|9|8|
 *
 * Rest 4-bits will be used by opcode encoding.
 * |15|14|13|12|
 *
 * So an "LOAD reg0 #20" instruction would assume following encoding:
 * <0001> <0000> <00010100>
 * or 0x1014 is the hex representation of given instruction.
 */

 /*
  * Sample program with an instruction set
  */

unsigned int code[] = {0x1014,
                       0x110A,
                       0x2201,
                       0x0000};

/*
 * Instruction cycle: Fetch, Decode, Execute
 */

/*
 * Current state of machine: It's a binary true/false
 */

int running = TRUE;

/*
 * Fetch
 */
int fetch()
{
  /*
   * Program Counter
   */
  static int pc = 0;

  if (pc == NUM_REGS)
    return INVALID;

  return code[pc++];
}

void decode(int instr, VMData *t)
{
  t->op   = (instr & 0xF000) >> 12;
  t->reg1 = (instr & 0x0F00) >> 8;
  t->reg2 = (instr & 0x00F0) >> 4;
  t->reg3 = (instr & 0x000F);
  t->scal = (instr & 0x00FF);
}

void execute(VMData *t)
{
  switch(t->op) {
    case 1:
      /* LOAD */
      printf("\nLOAD REG%d %d\n", t->reg1, t->scal);
      regs[t->reg1] = t->scal;
      break;

    case 2:
      /* ADD */
      printf("\nADD %d %d\n", regs[t->reg2], regs[t->reg3]);
      regs[t->reg1] = regs[t->reg2] + regs[t->reg3];
      printf("\nResult: %d\n", regs[t->reg1]);
      break;

    case 0:
    default:
      /* Halt the machine */
      printf("\nHalt!\n");
      running = FALSE;
      break;
    }
}

void run()
{
  int instr;
  VMData t;

  while(running)
  {
    instr = fetch();

    if (INVALID == instr)
      break;

    decode(instr, &t);
    execute(&t);
  }
}

int main()
{
  run();
  return 0;
}

The primary components of a register VM are:

1. A register set: Simulated with an array of integers acting as read/write memory cells.
2. An instruction set: What operations, and how many operands, should we support?
   • Our primitive VM supports addition, load and halt operations.
   • Addressing mode: Operands are part of the instructions, so an instruction decode would unveil the associated operands.
3. Execution unit: The engine works similar to a CPU:
   • It fetches the next instruction from the program.
   • It decodes the instruction to figure out the type of operation and operands.
   • It executes the decoded instruction.

References

• Dalvik Virtual Machine
• Lua programming language
• Wikipedia on virtual stack machines
• Paper titled “Virtual Machine Showdown: Stack Versus Registers” [PDF]

The X Window System has a very distinct place in Linux history. Originally developed at MIT in 1984, X works with multiple applications simultaneously, generating text and graphics in monochrome, colour and bitmap display. X also provides facilities for generating multi-font text and two-dimensional structures like lines, polygons and circles. X even provides a basic framework for building graphical user interfaces. X is simply another application sitting on the top of the Linux kernel.

To start with, you may be confused between X Window System and Xlib. Actually, X is fundamentally composed of network protocols, which are quite complex, and consist of bits and message transfers. To reduce complexity, different libraries handle the complexity internally, providing programmers with an API. Xlib is the library for the C programming language.

The history and design of X

X was created as a research project in the early 80s. The committee responsible for X is the MIT X Consortium. The lead programmer was Robert Schiefler. In the early 90s, X was ported to run on Linux — an architecture that was known as the XFree86 system. XFree86 provides a client/server interface between the display hardware and the desktop environment.

With X, it was possible, for the first time, to write programs for an entire class of machines, rather than limited to a particular hardware manufacturer. Programmers could write programs that ran on almost any combination of hardware—possibly without even recompiling them.

Let us now look at the client-server architecture of X. The server is the program that controls the display, while user applications are clients. The server passes user inputs to the respective/active client program, and displays the information provided by the client program. The server acts as an intermediary between clients running on local or remote systems, and the resources of the local or remote system.

The design of X introduced the idea of X terminals — thin clients that ran only an X server and connected to a large server computer to actually run useful programs. These were executed on the server system, and were displayed to the user on the terminal. The X client-server architecture even enabled users to have X programs display their output on a Windows system, while the program itself ran on a UNIX machine — which actually is one of the most significant features of X. The following figure gives a schematic diagram of how this works.

Schematic diagram explaining the working of X

X clients (programs) are written using Xlib to communicate with the X protocol. The X protocol defines each packet of information that is transferred between the server and Xlib, which is in one of the following forms:

• Request (from Xlib to the server): Information like specifications for circles.
• Reply (from server to Xlib): In certain requests, there is a reply.
• Events (from server to Xlib): Information of the user action like a mouse click.
• Errors (to the client): Errors are handled by an error-handling routine in Xlib.

X clients do not actually control display-related attributes like the window size or position. In fact, clients must not be dependent on a particular window configuration, though a client can give hints about how long, and where it would like to be displayed. The screen layout and the style of user interaction with the system, are managed by an X Window manager.

Some of you might be wondering how the requests are handled. Well, Xlib groups requests, instead of sending them one by one. This grouping also helps improve network performance, as the longer and less frequent transfers reduce the overall load.

Normally, after an event arrives at a client, the application generates more requests to draw—for example, highlighting the border of a button when the user moves the mouse pointer over it. These responses stay queued in Xlib, until all the events that have already arrived have been processed.

The schematic diagram above gives a clear picture about the whole process. When an application starts, all the requests that create the initial appearance (like a splash image) are queued up by Xlib. After the initial loading is done, the application waits for user input from the server. After the user activity is detected, the server sends the requests to Xlib.

Please note that the server does not queue or group requests; it acts immediately on any request received from the user or Xlib. Here, Xlib sends the requests to the client in the order in which they were received. In case there is an error, the application throws an error message to the server, and it generates the necessary output.

What’s next?

This article was purely theoretical, and aimed to generate awareness about Xlib. I would personally recommend that you understand all the concepts, to better enable you to write a program in Xlib with a proper flow. This is important, because you have to open and close a connection with the server; undetanding the flow lets you know which function to use at which point in time.

In the next article, I will demonstrate a simple program for plotting a series of points in a graph. The concepts explained in this part will definitely have an impact on your further understanding. See you soon!

It’s a Saturday morning, as I feed these words into a word processor. I have a browser running in the background, with a page on eBay open in one tab, and Engadget in another. The sheer simplicity of browsing through the product catalogues on eBay, or reading the latest and greatest tech news on Engadget, is living proof of the power of the database. The information age, the social networking age, the collaborative age, or whatever “age” you may want to call it, all revolve around data.

Shouldn’t the information age be revolving around, well, information? At this point, I would like to highlight a key difference between information and data. Information is processed data. From a philosophical standpoint, it has been wonderfully put by Gene Bellinger, Durval Castro and Anthony Mills in their article, aptly titled, “Data, Information, Knowledge, and Wisdom”; the cumulative order would be Data < Information < Knowledge < Understanding < Wisdom.

As far as computing goes in day-to-day contexts, the buck stops at information databases, which, as the word suggests, deal with what underlies information, i.e., data. Consider the product page on eBay. All you see is information, the cohesive form, which consists of the product images, the description, the price, information about the seller, etc. The data is beneath this processed presentation in the browser.

In this example, the individual components are data — like the words in the description. The words, by themselves, can’t stand independently on the page. Only when they are in context with one another, and with other data, do they convey something that makes sense. When they are processed, they turn into information.

The domain of databases is vast, and fills volumes and volumes of mammoth publications. The scope of this article is to give you a taste and understanding of databases, how to go about designing one, and I will conclude with designing an actual but hypothetical database, and implementing it.

So, what are databases?

Databases are structures that hold data. The software that enables the flow of data through these structures is called a database management system or DBMS. The most widely used system of DBMS is something called RDBMS or Relational DBMS. This simply means that the data is stored in tables; moreover, whatever relationships that exist within the data are stored within tables.

To put it simply, there are three parts that make a database:

1. Tables: We all know what tables are — a matrix of rows and columns. In databases, it’s the same. Each row is a record, or a unit of data. A record (row) can have several columns or fields. Each field is like an attribute of that record.
2. Queries: A query is a question posed to the database, to retrieve a specific set of records, based on conditions supplied in the query.
3. Views: These are virtual tables, or (a set of) stored queries.

At a physical level, the data is stored in data files specific to the DBMS. Examples of modern-day RDBMSs that are widely used include Oracle, MySQL, etc. Oracle is the largest commercially available RDBMS, and MySQL (earlier acquired by Sun, and subsequently by Oracle) is a free and open source RDBMS that is very well-known.

Some other (important) concepts

A database is accessed, read from and written to, using an interface that allows applications to store and retrieve data. This interface is called an interface driver or database driver. There is usually more than one driver for an RDBMS. ODBC (Open DataBase Connectivity) is a popular database driver. So, if you write a program that needs to store and read data, you would use the API (Application Programming Interface — a collection of functions) provided by ODBC to do so. Similarly, there is JDBC (Java DataBase Connectivity) and others.

Let’s suppose you are making a payment online, and the power goes out at the least opportune moment, say, just when you hit the Pay button (as we all know, Murphy’s Law never fails us; it’s like gravity, I guess). Did the money get deducted from your bank account? If it did, did the merchant receive it? If so, does the system know that it happened successfully?

There are so many steps involved after you push that Pay button on Amazon, eBay or any e-commerce site; like the various messages exchanged between the participating banks, the merchant and the buyer (you). Once the power comes back, you can see what happened: the money has gone from your account, but the order status is Unpaid. The seller says he didn’t receive the money.

This is where the concept of a transaction comes in. If one step in the multitude of steps fails, then the action won’t happen. It’s an all-or-nothing scenario. Either your purchase will be complete, with all steps successful, or nothing happens. There is no in-between state. So, in our example, the bank will roll back the changes, and the money will reappear (depending, of course, on the bank’s time policies).

It’s about ACID

ACID stands for atomicity, consistency, isolation and durability. We have just seen what transactions are all about. The concept of ACID is nothing but a set of properties that define a successful execution of a transaction.

The all-or-nothing attribute of the transaction is called atomicity. The data must be valid for the transaction to be successful; this is the consistency of the transaction. In the above example, it’s a guaranteed possibility that there will be many buyers making purchases on the site. The RDBMS must take care that each transaction is isolated from the rest, to prevent data with errors. This is the isolation of the transaction.

And finally, we have durability, which is an assurance that the RDBMS makes that when the transaction completes successfully, it stays that way—irrespective of any form of failure that may occur once the transaction completes. It’s also a way to make sure that the transaction is rolled back if it has failed intermediately.

Getting in touch with the data: SQL

The theory part is fundamentally in place now. But how does one actually communicate with an RDBMS? This is done by what’s called SQL (Structured Query Language; pronounced “sequel”). SQL is pretty easy to understand, since it’s like broken English. I’ll give you an example: There is a table that stores the names, addresses, cities, countries and phone numbers of college students. I want the RDBMS to show me all students who are from, say, Mumbai. This would be the SQL statement for that query:

SELECT * FROM STUDENT_MASTER WHERE city='Mumbai';

Here, the asterisk (*) is synonymous to all — it’s a wild-card character. The query will return all rows where the city is Mumbai. This SQL statement can be passed on to the RDBMS via an API function call in code, or through an application like phpMyAdmin. Upon receiving the query, the system returns the records as per the query. Suppose we want only names of the students from Mumbai, and not whole records (we don’t want their addresses, phone numbers or countries of origin), the query would then become:

SELECT name FROM STUDENT_MASTER WHERE city='Mumbai';

Note that the word Mumbai is in quotes because it is text. Numbers won’t have quotes in a query. And the statement must end in a semi-colon.

For the next part of this article, I will be using MySQL to create the database. Here’s a quick way to go about installing and using it:

• Windows users: Download MySQL from its website (it’s called the MySQL Community Server). Just run the installer, and you should be okay.
• Linux users: Use the package manager and install mysql; alternatively, you can build it from source, if you wish to.

You can start MySQL through the command prompt (Windows) or terminal (Linux), by running mysql -u root -p. It will ask you for a password; keep it blank since the default is blank. You can change it later.

Types of SQL statements

SQL statements can be classified into the following four categories:

• DDL (Data Definition Language): This class of statement is used to create/destroy or define/change database components. Examples: CREATE, DROP, RENAME.
• DML (Data Manipulation Language): As the name suggests, these statements manipulate the data itself, and the views related to it. Examples: SELECT, INSERT.
• DCL (Data Control Language): These statements control access to the data. There are only two of them: GRANT and REVOKE.
• TCL (Transaction Control Language): Transactions are handled using these statements. Examples: COMMIT, ROLLBACK.

Designing a database

Here’s where we design a database for some simple data. Let’s say you want to make a database to store the names, addresses, phone numbers and birthdays of your friends and relatives. The first step is to see what kind of data you want to store:

• Names
• Addresses
• Phone Numbers
• Birthdays

Let’s begin by creating the database in MySQL:

mysql> CREATE DATABASE mycontacts;
Query OK, 1 row affected (0.00 sec)

mysql> USE mycontacts;
Database changed

The USE command tells MySQL which database you want to be working on in this session. You can list the available databases using the following command:

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mycontacts         |
| mysql              |
| phpmyadmin         |
+--------------------+
4 rows in set (0.05 sec)

Now let’s go table by table, and see what columns to put into each. These are the columns I put in:

1. Names:
   • contact_id
   • name
2. Addresses:
   • contact_id
   • address_line1
   • address_line2
   • city
   • country
   • email
3. Phone Numbers:
   • contact_id
   • landline
   • mobile
4. Birthdays:
   • contact_id
   • birthdate

So, we can now make four tables: NAMES_MASTER, ADDRESS_MASTER, PHONE_MASTER and BIRTHDAY_MASTER. The MySQL command for making NAMES_MASTER would be:

mysql> CREATE TABLE NAMES_MASTER (
       contact_id INT,
       name VARCHAR(50)
       );
Query OK, 0 rows affected (0.14 sec)

Other tables can be made similarly. VARCHAR and INT are data-types. INT stands for integer. VARCHAR is a variable character. It’s a dynamically changing field, whose size depends on the entered data. The VARCHAR(50) means the field can have a maximum size of fifty characters. Other supported data-types are listed in the MySQL documentation.

Now let’s explore the concept of primary and secondary keys. If you notice, the field contact_id is common to all tables. This is to relate the tables by that common field. Here, the contact_id in NAMES_MASTER is the primary key, and the rest are secondary keys. In other words, contact_id is the reference for all the data in each table (as the secondary key), where it finally relates to the name of the contact (as primary key).

Once a table is made, you can populate it using a tool called phpMyAdmin. Doing justice to using phpMyAdmin would require another article; hence, I won’t cover this aspect here. You can also populate using the INSERT statement:

INSERT into table_name (column1, column2...)
                              values (value1, value2...);

At the end of this exercise, you will have a database ready to use. This, frankly, is just the starting point in designing a database. I hope it proved helpful to you in understanding what goes on beneath the surface in cyberspace, at least when it comes to managing data.

Why is there a need for load balancers? While managing a Web services infrastructure, Web administrators often find it a challenge to cope with increased website hits, while maintaining high availability of the servers. This situation gets even tougher when a new Web application or functionality is released, attracting more users per day.

Optimisation of server performance is thus a continuous job. Consider a Web server hosting a site running a few applications. When the site gains more users, there are many more page requests. Serving each request uses a definite amount of CPU, memory and network resources. Adding powerful resources can only solve the problem to some extent, while introducing other challenges. When the Web server hits the ceiling in terms of its resource limit, it starts dropping Web requests, which results in a bad user experience — a “broken” Web page.

And if the Web server goes down, for some reason, the entire site becomes non-functional. This can certainly result in a loss of reputation, and in some cases, also a monetary loss for the organisation. To preempt such situations, IT management teams must deploy load-balancing solutions in the data-centre infrastructure. We will soon discuss how a load balancer can not only distribute traffic, but also help ease network operations tasks.

How does a load balancer work?

First-generation balancing devices were implemented around BSD UNIX versions. A new trend of balancing products is typically in the form of an appliance running a Linux distribution; some enterprise-grade appliances use Red Hat or similar Linux flavours.

Figure 1: Typical load balancer setup

Functionally, a load balancer can balance traffic by distributing it among two or more servers. Figure 1 shows a typical Web farm configuration with a load-balancing device that acts as a front-end server to handle all Web requests. Each silo hosts a different set of applications, whereas all servers in a given silo host identical applications.

From the configuration point of view, the device is configured with two separate IP ranges. One is used to handle incoming traffic, and the other, called virtual servers, is used to connect to the nodes under its control. Thus, it forms an agent service between the requesting client and the responding server. It also acts on the requests intelligently, based on the configured rules, to choose a recipient node with the least workload at that particular time.

Rules define how a request should be handled, and also how to handle special conditions such as node preference, session management, etc. The load-balancing device then makes a separate TCP connection with the recipient Web server, and redirects the requests to it, while it keeps track of the request processing.

In the technical sense, a load balancer balances underlying TCP connections, rather than actual Web requests. It is a misconception that a load balancer checks resource utilisation (such as CPU, memory, etc.) on a controlled server. In reality, it simply checks the network response time of a server, which is a result of the server’s overall resource utilisation. Since it acts as a catalyst in improving the scalability of a server farm, it maintains data for each node under its control, like the number of requests processed in history, the response time by each host for requests, the fault trend of each host, etc.

In earlier days, load balancing solutions were implemented around simple round-robin techniques, which did help distribute the load, but did not provide fault tolerance features, since they lacked the necessary intelligence. In today’s advanced data centres, load balancers are used to effectively distribute traffic for Web servers, databases, queue managers, DNS servers, email and SMTP traffic, and almost all applications which use IP traffic. Balancing DNS servers helps distribute DNS queries to servers that are dispersed geographically, which is useful for disaster-recovery implementations.

Using load balancers to achieve fault tolerance

In a server farm, servers often experience downtime due to unforeseen resource failure or scheduled maintenance. These resource failures can be at the hardware level or simply at the software application level. In a business-critical infrastructure, such situations should be transparent, never affecting the user. As discussed earlier, since the balancing device maintains separate TCP connectivity with the controlled node, it can be further used to achieve fault tolerance.

A configurable “heart beat”, called a monitor, is maintained by the balancer with each node. This can be a simple ICMP ping, or an FTP/HTTP connection to retrieve data. Upon an appropriate response from the node, the load balancer becomes aware that the node is live, and marks it as an active participant eligible for the balancing process. If the server or its application resource fails, the balancer waits for a certain period of time for a “heart beat” from the node; upon non-compliance, it marks that node as a non-participant, and removes it from the silo.

Once marked thus, the load balancer doesn’t send traffic to that node. However, it still keeps polling to see if the node is back online, and if found to be so, marks the node as an active participant again and starts sending traffic to it. If a fault situation occurs while the request is being transferred to a node, modern load balancers are capable of detecting that too, and taking (configurable) corrective action.

This feature can further be explored by the operations team for maintenance purposes. A service instance can be configured on a node — for example, a separate Web instance running under a separate IP address, with a dummy page on it. A monitor can be configured to access that page periodically. If the server is to be taken offline for maintenance purposes, the operations person can stop the dummy site, which results in the server being marked as a non-participant.

It can then be shut down or have other administration work done on it. Once maintenance is completed, the dummy site service can be started again, bringing the server back into the silo. This feature can be further extended by configuring many such monitors at the application level that can be reported upon in a dashboard via a network monitoring product, for an operations admin view.

Layer 7 load balancing

Earlier versions of load balancers used to work at the OSI model Layer 2 (link aggregation), or Layer 4 (IP-based). Since the requests flow through the balancing devices, it made sense to read into the requests at Layer 7, to bring additional flexibility in balancing techniques. Adding such flexibility offers higher scalability, better manageability and high availability.

Layer 7 load balancing primarily operates on the following three techniques:

1. URL parsing
2. HTTP header interception
3. Cookie interception

Typically, a Layer 7 rule structure looks somewhat like the one shown below. However, the exact syntax varies for each vendor and device model. As seen in the example, a request is first parsed based on the virtual directory being accessed, then by a particular cookie field’s content, and is finally sent to a default pool, if the first two conditions are not matched.

{
if (http_qstring, "/") = "mydir"
   sendto server_pool1
else{
if cookie("mycookie") contains "logon_cookie"
   sendto server_pool2
else {
   sendto server_pool3
}

Since the request is intercepted and interpreted at Layer 7, the possibilities of adding intelligence grow exponentially. Rules can be configured to distribute traffic based on a field in the HTTP header, the source IP address or custom cookie fields, to name just a few. There are endless possibilities to make intelligent traffic distributions.

For example, if the incoming request is from a smartphone, it can be sent to servers hosting mobile applications. If the request is for a URL that hosts a simple HTML-based site, it can be routed to an economical server farm. If a login cookie is not present in the request, it can be sent to a login server, avoiding loading down other busy servers.

As the Layer 7 rules bring programmability to balancing techniques, they can further be explored for the benefit of the technology operations staff. When a roll-out of a newer version is planned in an existing database server farm, the new set of servers can be configured as a separate pool to perform migration mock-tests, and can be brought online once the tests are passed.

In case the roll-out experiences problems, merely switching pools back to the original settings can achieve a rollback with minimum downtime. As another example, many mission-critical Web farms require to maintain legacy server operating systems for stability reasons, while new applications demand the latest and greatest platforms. In such cases, separate server pools can be configured for new applications, and traffic distribution can be achieved by checking Web request URLs at Layer 7.

Load balancing at Layer 7 also helps improve the return on investment (RoI) of an IT infrastructure. Consider a Web portal which caters to a high volume of users with Web pages that are content rich, with JavaScript and images. Since the scripts and images don’t change quite often, these can be treated as static content, and hosted on a separate set of servers. As a result, the Web servers running important business logic use fewer resources, which means that we can accommodate more users per server, or host more applications per server, and thus reduce the effective cost of hosting. This also proves that a carefully configured Layer 7 load balancer can achieve higher application performance throughputs on a given data-centre infrastructure footprint.

Additional features in a load balancer appliance

Besides powerful traffic distribution features, most industry-grade modern load balancers also come with features which are essential to take additional tasks from the managed nodes, or other infrastructure components. SSL negotiation is one such feature that can handle heavy volumes of SSL handshaking — which would otherwise take a performance toll on Web servers. Another great feature is cookie persistence, which helps applications stick to a particular server, in order to maintain a stateful session with it.

Many new load-balancer trends provide admin features such as traffic monitoring and TCP buffering; security features such as content filtering, and an intrusion detection firewall; and also performance-based features such as HTTP caching, HTTP compression, etc. Since a load-balancing device is a front-end component in a server farm, it comes equipped with high-speed network ports, such as Gigabit Ethernet and fibre connections.

Open source load-balancing solutions

Multiple vendors provide industry-grade enterprise load-balancing solutions, such as F5 networks (BigIP), Citrix Netscaler, Cisco, Coyote Point, etc. These devices are rich in features, provide flexible rule programmability, and exhibit high performance throughput — but they do come with a price tag and support cost.

For those who are interested in FOSS, there are multiple distributions available on the Linux platform, which offer features from simple load balancing to full-featured appliance-grade products. Let’s look at three such ‘most wanted’ solutions.

LVS (Linux Virtual Server) is one famous solution, which has proved to be industry-grade software, and can be used to build highly scalable and available Linux cluster servers to cater to high volumes of Web requests. It comes with ample documentation, which helps build a load-balanced farm, step by step.

Ultra Monkey is another interesting solution, which provides failover features in addition to basic load balancing: if one load-balancer device fails, the other can take over to provide device-level fault tolerance. It supports multiple Linux flavours such as Fedora, Debian, etc.

Another powerful, but lesser-known implementation is Crossroads for Linux, which is a TCP-based load balancer providing a very basic form of traffic distribution. The beauty of this product is that its source code can be easily modified to serve just one task, such as DNS or Web balancing, without any bells and whistles — thus achieving a very high performance for that single purpose.

Configuring Layer 7 rules on a load balancer is an art, and needs a deep understanding of networking protocols and server operations. Features of load balancers can also be used as an aid to the operations and maintenance tasks.

Before we explore Apache’s middleware offering, it’s important to know the various types of middleware out there. Middleware are classified into types based on the primary functions they perform. A popular classification is by Judith Hurwitz, in her paper, Sorting Out Middleware, according to which middleware can be:

• Embedded middleware: As the name suggests, this type of middleware handles embedded applications (software or firmware).
• RPC middleware: RPC (Remote Procedure Call) middleware communicates with applications using calls
• Object request broker: Here, applications can send and receive objects.
• SQL-oriented data access middleware: Primarily meant for database-related applications, this class of middleware sits between applications that communicate with databases.
• Message-oriented middleware: This is where Apache ActiveMQ fits in. Message-oriented middleware mediate the communication or messages, between applications.

Introducing Apache ActiveMQ

One of the best open source solutions for message broking is Apache ActiveMQ. It is a prime product used in enterprise environments, because it supports advanced features such as multiple instances to store messages, and clustering environments.

The backbone of ActiveMQ is what’s known as JMS — the Java Messaging Service. JMS is an API implementation within J2EE (Java Enterprise) which is specifically for message-oriented applications.

Features of ActiveMQ

There is a long list of features on the ActiveMQ website, but I will highlight and discuss the key ones:

• Cross-language compliance and compatibility: This is an important feature, since applications may be written in different languages like C/C++, Python, Ruby, Java, etc. Allowing cross-language compatibility allows communication between very diverse applications, and allows seamless integration. This is probably the most important feature for message-oriented middleware.
• AJAX and REST support: Web services and applications can easily communicate, since AJAX and REST are part of the core of Web services and applications out there.
• Compatible with various transport protocols: Important because messages can be transferred effectively only if there is a wide variety of protocols for transport. Examples of transport protocols include TCP (Transmission Control Protocol), UDP (User Datagram Protocol) and SSL (Secure Socket Layer).
• Support for persistence: In computing terms, persistence is the capability of an application to preserve its state. In other words, it’s the ability of the application to remember. This is done by the program recording what it needs to remember in text files or databases. In the context of ActiveMQ, persistence is used mainly for the database-linked persistence of applications.
• High-performance computing and high availability: In simple words, this is nothing but ensuring that any form of failure doesn’t affect the user. This is achieved mainly through clustering. Here, many instances of the application (either on the same machine, but usually spread across multiple physical machines) are running, in such a way that if one instance fails, another one takes over. This mission-critical feature is a big plus in ActiveMQ.

Usage scenario

The product is great, sounds completely robust and the features are fine and dandy, but where is it used? I will demonstrate a scenario where ActiveMQ (or usually any message-broking middleware) would work. For the sake of an explanation, I will cite a specific scenario where ActiveMQ behaves like a message bus — or, more specifically, an enterprise service bus. Figure 1 is a diagram that will explain it.

Figure 1: The Enterprise Service Bus (ESB) concept

Other popular open source middleware

Apart from ActiveMQ, the world of enterprise computing is full of other open source middleware. Here are some examples, with a short description of each.

• JDBC: The famous Java DataBase Connectivity API is an SQL-Oriented Data Access middleware. It allows Java programs to have database access, and thus be persistent. Another similar one is ODBC (Open DataBase Connectivity).
• CORBA: Developed by the Object Management Group (OMG), the Common Object Request Broker Architecture is a class of middleware that fits the object-broker type. Essentially, it allows communication between many applications and software components to exchange objects, even when they are written in different languages and are running on different computers. Note that CORBA is a standard, and not middleware, per se. A popular open source implementation of CORBA is MICO (MICO is a recursive acronym for Mico Is COrba).

This is an introduction to the concept of middleware. It goes way deeper than the scope of this article, but hopefully what you read here will help you as a starting point. Happy learning!

Shweta, at her PC in her hostel room, was all set to explore the characters of Linux character drivers, before it was taught in class. She recalled the following lines from professor Gopi’s class: “… today’s first driver would be the template for any driver you write in Linux. Writing any specialised/advanced driver is just a matter of what gets filled into its constructor and destructor…”

With that, she took out the first driver’s code, and pulled out various reference books, to start writing a character driver on her own. She also downloaded the online book, Linux Device Drivers by Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman. Here is the summary of what she learnt.

W’s of character drivers

We already know what drivers are, and why we need them. What is so special about character drivers? If we write drivers for byte-oriented operations (or, in C lingo, character-oriented operations), then we refer to them as character drivers. Since the majority of devices are byte-oriented, the majority of device drivers are character device drivers.

Take, for example, serial drivers, audio drivers, video drivers, camera drivers, and basic I/O drivers. In fact, all device drivers that are neither storage nor network device drivers are some type of a character driver. Let’s look into the commonalities of these character drivers, and how Shweta wrote one of them.

The complete connection

Figure 1: Character driver overview

As shown in Figure 1, for any user-space application to operate on a byte-oriented device (in hardware space), it should use the corresponding character device driver (in kernel space). Character driver usage is done through the corresponding character device file(s), linked to it through the virtual file system (VFS). What this means is that an application does the usual file operations on the character device file. Those operations are translated to the corresponding functions in the linked character device driver by the VFS. Those functions then do the final low-level access to the actual device to achieve the desired results.

Note that though the application does the usual file operations, their outcome may not be the usual ones. Rather, they would be as driven by the corresponding functions in the device driver. For example, a write followed by a read may not fetch what has just been written to the character device file, unlike for regular files. Remember that this is the usual expected behaviour for device files. Let’s take an audio device file as an example. What we write into it is the audio data we want to play back, say through a speaker. However, the read would get us audio data that we are recording, say through a microphone. The recorded data need not be the played-back data.

In this complete connection from the application to the device, there are four major entities involved:

1. Application
2. Character device file
3. Character device driver
4. Character device

The interesting thing is that all of these can exist independently on a system, without the other being present. The mere existence of these on a system doesn’t mean they are linked to form the complete connection. Rather, they need to be explicitly connected. An application gets connected to a device file by invoking the open system call on the device file.

Device file(s) are linked to the device driver by specific registrations done by the driver. The driver is linked to a device by its device-specific low-level operations. Thus we form the complete connection. With this, note that the character device file is not the actual device, but just a place-holder for the actual device.

Major and minor numbers

The connection between the application and the device file is based on the name of the device file. However, the connection between the device file and the device driver is based on the number of the device file, not the name. This allows a user-space application to have any name for the device file, and enables the kernel-space to have a trivial index-based linkage between the device file and the device driver. This device file number is more commonly referred to as the <major, minor> pair, or the major and minor numbers of the device file.

Earlier (till kernel 2.4), one major number was for one driver, and the minor number used to represent the sub-functionalities of the driver. With kernel 2.6, this distinction is no longer mandatory; there could be multiple drivers under the same major number, but obviously, with different minor number ranges.

However, this is more common with the non-reserved major numbers, and standard major numbers are typically preserved for single drivers. For example, 4 for serial interfaces, 13 for mice, 14 for audio devices, and so on. The following command would list the various character device files on your system:

$ ls -l /dev/ | grep "^c"

<major, minor> related support in kernel 2.6

Type (defined in kernel header linux/types.h):

• dev_t contains both major and minor numbers

Macros (defined in kernel header linux/kdev_t.h):

• MAJOR(dev_t dev) extracts the major number from dev
• MINOR(dev_t dev) extracts the minor number from dev
• MKDEV(int major, int minor) creates the dev from major and minor.

Connecting the device file with the device driver involves two steps:

1. Registering for the <major, minor> range of device files.
2. Linking the device file operations to the device driver functions.

The first step is achieved using either of the following two APIs, defined in the kernel header linux/fs.h:

+ int register_chrdev_region(dev_t first, unsigned int cnt, char *name);
+ int alloc_chrdev_region(dev_t *first, unsigned int firstminor, unsigned int cnt, char *name);

The first API registers the cnt number of device file numbers, starting from first, with the given name. The second API dynamically figures out a free major number, and registers the cnt number of device file numbers starting from <the free major, firstminor>, with the given name. In either case, the /proc/devices kernel window lists the name with the registered major number. With this information, Shweta added the following into the first driver code:

#include <linux/types.h>
#include <linux/kdev_t.h>
#include <linux/fs.h>

static dev_t first; // Global variable for the first device number

In the constructor, she added:

if (alloc_chrdev_region(&first, 0, 3, "Shweta") < 0)
{
    return -1;
}
printk(KERN_INFO "<Major, Minor>: <%d, %d>\n", MAJOR(first), MINOR(first));

In the destructor, she added:

unregister_chrdev_region(first, 3);

It’s all put together, as follows:

#include <linux/module.h>
#include <linux/version.h>
#include <linux/kernel.h>
#include <linux/types.h>
#include <linux/kdev_t.h>
#include <linux/fs.h>

static dev_t first; // Global variable for the first device number

static int __init ofcd_init(void) /* Constructor */
{
    printk(KERN_INFO "Namaskar: ofcd registered");
    if (alloc_chrdev_region(&first, 0, 3, "Shweta") < 0)
    {
        return -1;
    }
    printk(KERN_INFO "<Major, Minor>: <%d, %d>\n", MAJOR(first), MINOR(first));
    return 0;
}

static void __exit ofcd_exit(void) /* Destructor */
{
    unregister_chrdev_region(first, 3);
    printk(KERN_INFO "Alvida: ofcd unregistered");
}

module_init(ofcd_init);
module_exit(ofcd_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Anil Kumar Pugalia <email_at_sarika-pugs_dot_com>");
MODULE_DESCRIPTION("Our First Character Driver");

Then, Shweta repeated the usual steps that she’d learnt for the first driver:

• Build the driver (.ko file) by running make.
• Load the driver using insmod.
• List the loaded modules using lsmod.
• Unload the driver using rmmod.

Summing up

Additionally, before unloading the driver, she peeped into the /proc/devices kernel window to look for the registered major number with the name “Shweta”, using cat /proc/devices. It was right there. However, she couldn’t find any device file created under /dev with the same major number, so she created them by hand, using mknod, and then tried reading and writing those. Figure 2 shows all these steps.

Figure 2: Character device file experiments

Please note that the major number 250 may vary from system to system, based on availability. Figure 2 also shows the results Shweta got from reading and writing one of the device files. That reminded her that the second step to connect the device file with the device driver — which is linking the device file operations to the device driver functions — was not yet done. She realised that she needed to dig around for more information to complete this step, and also to figure out the reason for the missing device files under /dev.

We will deal with her further learning in our next article.

Enthused by how Pugs impressed their professor in the last class, Shweta wanted to do so too. And there was soon an opportunity: finding out where the output of printk had gone. So, as soon as she entered the lab, she grabbed the best system, logged in, and began work. Knowing her professor well, she realised that he would have dropped a hint about the possible solution in the previous class itself. Going over what had been taught, she remembered the error output demonstration from insmod vfat.ko — running dmesg | tail. She immediately tried that, and found the printk output there.

But how did it come to be here? A tap on her shoulder roused her from her thoughts. “Shall we go for a coffee?” proposed Pugs.

“But I need to –”.

“I know what you’re thinking about,” interrupted Pugs. “Let’s go, I’ll explain you all about dmesg.”

Kernel message logging

Over coffee, Pugs began his explanation.

As far as parameters are concerned, printf and printk are the same, except that when programming for the kernel, we don’t bother about the float formats %f, %lf and the like. However, unlike printf, printk is not designed to dump its output to some console.

In fact, it cannot do so; it is something in the background, and executes like a library, only when triggered either from hardware-space or user-space. All printk calls put their output into the (log) ring buffer of the kernel. Then, the syslog daemon running in user-space picks them up for final processing and redirection to various devices, as configured in the configuration file /etc/syslog.conf.

You must have observed the out-of-place macro KERN_INFO, in the printk calls, in the last article. That is actually a constant string, which gets concatenated with the format string after it, into a single string. Note that there is no comma (,) between them; they are not two separate arguments. There are eight such macros defined in linux/kernel.h in the kernel source, namely:

#define KERN_EMERG "<0>"   /* system is unusable                */
#define KERN_ALERT "<1>"   /* action must be taken immediately	*/
#define KERN_CRIT "<2>"    /* critical conditions		*/
#define KERN_ERR "<3>"     /* error conditions			*/
#define KERN_WARNING "<4>" /* warning conditions		*/
#define KERN_NOTICE "<5>"  /* normal but significant condition	*/
#define KERN_INFO "<6>"    /* informational			*/
#define KERN_DEBUG "<7>"   /* debug-level messages		*/

Now depending on these log levels (i.e., the first three characters in the format string), the syslog user-space daemon redirects the corresponding messages to their configured locations. A typical destination is the log file /var/log/messages, for all log levels. Hence, all the printk outputs are, by default, in that file. However, they can be configured differently — to a serial port (like /dev/ttyS0), for instance, or to all consoles, like what typically happens for KERN_EMERG.

Now, /var/log/messages is buffered, and contains messages not only from the kernel, but also from various daemons running in user-space. Moreover, this file is often not readable by a normal user. Hence, a user-space utility, dmesg, is provided to directly parse the kernel ring buffer, and dump it to standard output. Figure 1 shows snippets from the two.

Figure 1: Kernel’s message logging

Kernel-specific GCC extensions

Shweta, frustrated since she could no longer show off as having discovered all these on her own, retorted, “Since you have explained all about printing in the kernel, why don’t you also tell me about the weird C in the driver as well — the special keywords __init, __exit, etc.”

These are not special keywords. Kernel C is not “weird C”, but just standard C with some additional extensions from the C compiler, GCC. Macros __init and __exit are just two of these extensions. However, these do not have any relevance in case we are using them for a dynamically loadable driver, but only when the same code gets built into the kernel. All functions marked with __init get placed inside the init section of the kernel image automatically, by GCC, during kernel compilation; and all functions marked with __exit are placed in the exit section of the kernel image.

What is the benefit of this? All functions with __init are supposed to be executed only once during bootup (and not executed again till the next bootup). So, once they are executed during bootup, the kernel frees up RAM by removing them (by freeing the init section). Similarly, all functions in the exit section are supposed to be called during system shutdown.

Now, if the system is shutting down anyway, why do you need to do any cleaning up? Hence, the exit section is not even loaded into the kernel — another cool optimisation. This is a beautiful example of how the kernel and GCC work hand-in-hand to achieve a lot of optimisation, and many other tricks that we will see as we go along. And that is why the Linux kernel can only be compiled using GCC-based compilers — a closely knit bond.

The kernel function’s return guidelines

While returning from coffee, Pugs kept praising OSS and the community that’s grown around it. Do you know why different individuals are able to come together and contribute excellently without any conflicts, and in a project as huge as Linux, at that? There are many reasons, but most important amongst them is that they all follow and abide by inherent coding guidelines.

Take, for example, the kernel programming guideline for returning values from a function. Any kernel function needing error handling, typically returns an integer-like type — and the return value again follows a guideline. For an error, we return a negative number: a minus sign appended with a macro that is available through the kernel header linux/errno.h, that includes the various error number headers under the kernel sources — namely, asm/errno.h, asm-generic/errno.h, asm-generic/errno-base.h.

For success, zero is the most common return value, unless there is some additional information to be provided. In that case, a positive value is returned, the value indicating the information, such as the number of bytes transferred by the function.

Kernel C = pure C

Once back in the lab, Shweta remembered their professor mentioning that no /usr/include headers can be used for kernel programming. But Pugs had said that kernel C is just standard C with some GCC extensions. Why this conflict?

Actually this is not a conflict. Standard C is pure C — just the language. The headers are not part of it. Those are part of the standard libraries built in for C programmers, based on the concept of reusing code.

Does that mean that all standard libraries, and hence, all ANSI standard functions, are not part of “pure” C? Yes, that’s right. Then, was it really tough coding the kernel?

Well, not for this reason. In reality, kernel developers have evolved their own set of required functions, which are all part of the kernel code. The printk function is just one of them. Similarly, many string functions, memory functions, and more, are all part of the kernel source, under various directories like kernel, ipc, lib, and so on, along with the corresponding headers under the include/linux directory.

“Oh yes! That is why we need to have the kernel source to build a driver,” agreed Shweta.

“If not the complete source, at least the headers are a must. And that is why we have separate packages to install the complete kernel source, or just the kernel headers,” added Pugs.

“In the lab, all the sources are set up. But if I want to try out drivers on my Linux system in my hostel room, how do I go about it?” asked Shweta.

“Our lab has Fedora, where the kernel sources are typically installed under /usr/src/kernels/<kernel-version>, unlike the standard /usr/src/linux. Lab administrators must have installed it using the command-line yum install kernel-devel. I use Mandriva, and installed the kernel sources using urpmi kernel-source,” replied Pugs.

“But I have Ubuntu,” Shweta said.

“Okay! For that, just use apt-get utility to fetch the source — possibly apt-get install linux-source,” replied Pugs.

Summing up

The lab session was almost over when Shweta suddenly asked, out of curiosity, “Hey Pugs, what’s the next topic we are going to learn in our Linux device drivers class?”

“Hmm… most probably character drivers,” threw back Pugs.

With this information, Shweta hurriedly packed her bag and headed towards her room to set up the kernel sources, and try out the next driver on her own. “In case you get stuck, just give me a call,” smiled Pugs.

“After a week of hard work, we finally got our driver working,” were Pugs’ first words when he met his girlfriend, Shweta.

“Why? What was your driver up to? Was he sick? And what hard work did you do?” asked Shweta. Confused, Pugs responded, “What are you talking about?”

Now it was Shweta’s turn to look puzzled, as she replied, “Why ask me? You tell me — which of your drivers are you talking about?”

When understanding dawned on him, Pugs groaned, “Ah c’mon! Not my car drivers — I am talking about a device driver on my computer.”

“I know about car and bus drivers, pilots, and even screwdrivers; but what is this ‘device driver’?” queried Shweta, puzzled.

That was all it took to launch Pugs into a passionate explanation of device drivers for the newbie — in particular, Linux device drivers, which he had been working on for many years.

Of drivers and buses

A driver drives, manages, controls, directs and monitors the entity under its command. What a bus driver does with a bus, a device driver does with a computer device (any piece of hardware connected to a computer) like a mouse, keyboard, monitor, hard disk, Web-camera, clock, and more.

Further, a “pilot” could be a person or even an automatic system monitored by a person (an auto-pilot system in airliners, for example). Similarly, a specific piece of hardware could be controlled by a piece of software (a device driver), or could be controlled by another hardware device, which in turn could be managed by a software device driver. In the latter case, such a controlling device is commonly called a device controller. This, being a device itself, often also needs a driver, which is commonly referred to as a bus driver.

General examples of device controllers include hard disk controllers, display controllers, and audio controllers that in turn manage devices connected to them. More technical examples would be an IDE controller, PCI controller, USB controller, SPI controller, I2C controller, etc. Pictorially, this whole concept can be depicted as in Figure 1.

Figure 1: Device and driver interaction

Device controllers are typically connected to the CPU through their respectively named buses (collection of physical lines) — for example, the PCI bus, the IDE bus, etc. In today’s embedded world, we encounter more micro-controllers than CPUs; these are the CPU plus various device controllers built onto a single chip. This effective embedding of device controllers primarily reduces cost and space, making it suitable for embedded systems. In such cases, the buses are integrated into the chip itself. Does this change anything for the drivers, or more generically, on the software front?

The answer is, not much — except that the bus drivers corresponding to the embedded device controllers are now developed under the architecture-specific umbrella.

Drivers have two parts

Bus drivers provide hardware-specific interfaces for the corresponding hardware protocols, and are the bottom-most horizontal software layers of an operating system (OS). Over these sit the actual device drivers. These operate on the underlying devices using the horizontal layer interfaces, and hence are device-specific. However, the whole idea of writing these drivers is to provide an abstraction to the user, and so, at the other “end”, these do provide an interface (which varies from OS to OS). In short, a device driver has two parts, which are: a) device-specific, and b) OS-specific. Refer to Figure 2.

Figure 2: Linux device driver partition

The device-specific portion of a device driver remains the same across all operating systems, and is more about understanding and decoding the device data sheets than software programming. A data sheet for a device is a document with technical details of the device, including its operation, performance, programming, etc. — in short a device user manual.

Later, I shall show some examples of decoding data sheets as well. However, the OS-specific portion is the one that is tightly coupled with the OS mechanisms of user interfaces, and thus differentiates a Linux device driver from a Windows device driver and from a MacOS device driver.

Verticals

In Linux, a device driver provides a “system call” interface to the user; this is the boundary line between the so-called kernel space and user-space of Linux, as shown in Figure 2. Figure 3 provides further classification.

Figure 3: Linux kernel overview

Based on the OS-specific interface of a driver, in Linux, a driver is broadly classified into three verticals:

• Packet-oriented or the network vertical
• Block-oriented or the storage vertical
• Byte-oriented or the character vertical

The CPU vertical and memory vertical, taken together with the other three verticals, give the complete overview of the Linux kernel, like any textbook definition of an OS: “An OS performs 5 management functions: CPU/process, memory, network, storage, device I/O.” Though these two verticals could be classified as device drivers, where CPU and memory are the respective devices, they are treated differently, for many reasons.

These are the core functionalities of any OS, be it a micro-kernel or a monolithic kernel. More often than not, adding code in these areas is mainly a Linux porting effort, which is typically done for a new CPU or architecture. Moreover, the code in these two verticals cannot be loaded or unloaded on the fly, unlike the other three verticals. Henceforth, when we talk about Linux device drivers, we mean to talk only about the latter three verticals in Figure 3.

Let’s get a little deeper into these three verticals. The network vertical consists of two parts: a) the network protocol stack, and b)the network interface card (NIC) device drivers, or simply network device drivers, which could be for Ethernet, Wi-Fi, or any other network horizontals. Storage, again, consists of two parts: a) File-system drivers, to decode the various formats on different partitions, and b) Block device drivers for various storage (hardware) protocols, i.e., horizontals like IDE, SCSI, MTD, etc.

With this, you may wonder if that is the only set of devices for which you need drivers (or for which Linux has drivers). Hold on a moment; you certainly need drivers for the whole lot of devices that interface with the system, and Linux does have drivers for them. However, their byte-oriented cessibility puts all of them under the character vertical — this is, in reality, the majority bucket. In fact, because of the vast number of drivers in this vertical, character drivers have been further sub-classified — so you have tty drivers, input drivers, console drivers, frame-buffer drivers, sound drivers, etc. The typical horizontals here would be RS232, PS/2, VGA, I2C, I2S, SPI, etc.

Multiple-vertical drivers

One final note on the complete picture (placement of all the drivers in the Linux driver ecosystem): the horizontals like USB, PCI, etc, span below multiple verticals. Why is that?

Simple — you already know that you can have a USB Wi-Fi dongle, a USB pen drive, and a USB-to-serial converter — all are USB, but come under three different verticals!

In Linux, bus drivers or the horizontals, are often split into two parts, or even two drivers: a) device controller-specific, and b) an abstraction layer over that for the verticals to interface, commonly called cores. A classic example would be the USB controller drivers ohci, ehci, etc., and the USB abstraction, usbcore.

Summing up

So, to conclude, a device driver is a piece of software that drives a device, though there are so many classifications. In case it drives only another piece of software, we call it just a driver. Examples are file-system drivers, usbcore, etc. Hence, all device drivers are drivers, but all drivers are not device drivers.

“Hey, Pugs, hold on; we’re getting late for class, and you know what kind of trouble we can get into. Let’s continue from here, later,” exclaimed Shweta.

Jumping up, Pugs finished his explanation: “Okay. This is the basic theory about device drivers. If you’re interested, later, I can show you the code, and all that we have been doing for the various kinds of drivers.” And they hurried towards their classroom.