Objectives

• The HyperText Transfer Protocol and the Apache web server.

• The Common Gateway Interface.

• The Dynamic Host Configuration Protocol.

• The Network Time Protocol.

• The Network Address Translator and the Port Address Translator.

• An introduction to socket programming.

The HyperText Transfer Protocol

The HyperText Transfer Protocol and the Web

In the early days of the Internet, email, FTP, and remote login were the most popular applications. The first World Wide Web (WWW) browser was written by Tim Berners-Lee in 1990. Since then, WWW has become the second “Killer App” after email. Its popularity resulted in the exponential growth of the Internet.

In WWW, information is typically provided as HyperText Markup Language (HTML) files (called web pages). WWW resources are specified by Uniform Resource Locators (URL), each consisting of a protocol name (e.g., http, rtp, rtsp), a “://”, a server domain name or server IP address, and a path to a resource (an HTML file or a CGI script (see Section 8.2.2)). The HyperText Transfer Protocol (HTTP) is an application layer protocol for distributing information in the WWW. In common with many other Internet applications, HTTP is based on the client–server architecture. An HTTP server, or a web server, uses the well-known port number 80, while an HTTP client is also called a web browser.

Objectives

• Study sock as a traffic generator, in terms of its features and command line options.

• Study the User Datagram Protocol.

• IP fragmentation.

• MTU and path MTU discovery.

• UDP applications, using the Trivial File Transfer Protocol as an example.

• Compare UDP with TCP, using TFTP and the File Transfer Protocol.

The User Datagram Protocol

Since the Internet protocol suite is often referred to as TCP/IP, UDP, it may seem, suffers from being considered the “less important” transport protocol. This perception is changing rapidly as realtime services, such as Voice over IP (VoIP), which use UDP become an important part of the Internet landscape. This emerging UDP application will be further explored in Chapter 7.

UDP provides a means of multiplexing and demultiplexing for user processes, usingUDP port numbers. It extends the host-to-host delivery service of IP to the application-to-application level. There is no other transport control mechanism provided by UDP, except a checksum which protects the UDP header (see Fig. 0.14), UDP data, and several IP header fields.

Objectives

• Multicast addressing.

• Multicast group management.

• Multicast routing: configuring a multicast router.

• Realtime video streaming using the Java Media Framework.

• Protocols supporting realtime streaming: RTP/RTCP and RTSP.

• Analyzing captured RTP/RTCP packets using Ethereal.

IP multicast

IP provides three types of services, i.e., unicast, multicast, and broadcast. Unicast is a point-to-point type of service with one sender and one receiver. Multicast is a one-to-many or many-to-many type of service, which delivers packets to multiple receivers. Consider a multicast group consisting of a number of participants, any packet sent to the group will be received by all of the participants. In broadcasts, IP datagrams are sent to a broadcast IP address, and are received by all of the hosts.

Figure 7.1 illustrates the differences between multicast and unicast. As shown in Fig. 7.1(a), if a node A wants to send a packet to nodes B, C, and D using unicast service, it sends three copies of the same packet, each with a different destination IP address. Then, each copy of the packet will follow a possibly different path from the other copies. To provide a teleconferencing-type service for a group of N nodes, there need to be N(N - 1)/2 point-to-point paths to provide a full connection.

Objectives

• Network interfaces and interface configuration.

• Network load and statistics.

• The Address Resolution Protocol and its operations.

• ICMP messages and Ping.

• Concept of subnetting.

• Duplicate IP addresses and incorrect subnet masks.

Local area networks

Generally there are two types of networks: point-to-point networks or broadcast networks. A point-to-point network consists of two end hosts connected by a link, whereas in a broadcast network, a number of stations share a common transmission medium. Usually, a point-to-point network is used for long-distance connections, e.g., dialup connections and SONET/SDH links. Local area networks are almost all broadcast networks, e.g., Ethernet or wireless local area networks (LANs).

Point-to-Point networks

The Point-to-Point Protocol (PPP) is a data link protocol for PPP LANs. The main purpose of PPP is encapsulation and transmission of IP datagrams, or other network layer protocol data, over a serial link. Currently, most dial-up Internet access services are provided using PPP.

PPP consists of two types of protocols. The Link Control Protocol (LCP) of PPP is responsible for establishing, configuring, and negotiating the datalink connection, while for each network layer protocol supported by PPP, there is a Network Control Protocol (NCP). For example, the IP Control Protocol (IPCP) is used for transmitting IP datagrams over a PPP link. Once the link is successfully established, the network layer data, i.e., IP datagrams, are encapsulate in PPP frames and transmitted over the serial link.

Objectives

• SNMP and MIBs, using NET-SNMP as an example, and using NETSNMP utilities to query MIB objects.

• Encryption, confidentiality, and authentication, including DES, RSA, MD5 and DSS.

• Application layer security, using SSH and Kerberos as examples.

• Transport layer security, including SSL and the secure Apache server.

• Network layer security, IPsec and Virtual Private Networks.

• Firewalls and IPTABLES.

• Accounting, auditing, and intrusion detection.

Network management

The Simple Network Management Protocol

In addition to configuring network devices when they are initially deployed, network management requires the performing of many tasks to run the network efficiently and reliably. A network administrator may need to collect statistics from a device to see if it is working properly, or monitor the network traffic load on the routers to see if the load is appropriately distributed. When there is a network failure, the administrator may need to go through the information collected from the nearby devices to identify the cause. The Simple Network Management Protocol (SNMP) is an application layer protocol for exchanging management information between network devices. It is the de facto network management standard in the Internet.

Figure 9.1 illustrates a typical SNMP management scenario, consisting of an SNMP manager and multiple managed devices. A managed device, e.g., a host computer or a router, maintains a number of Management Information Bases (MIB), which record local management related information.

INTRODUCTION

The unified modeling language (UML) is a standardized language for modeling software systems. Although small systems are easy for a single person or a small group to comprehend and develop, large systems are more difficult to design successfully, since there are often many people and entities controlling different aspects of the system and defining how they should work from their own professional specialty or prerogative. For example, a large company requesting a new piece of software might assign the job to a project manager who has a thorough understanding of the overall system requirements, whereas a software developer assigned to work on the system is likely to care more about the ways that individual portions of a system work on a detailed level and less about the practical requirements of users and management. Similarly, an end user of the system is likely to care about how the user interface is organized and that the software is built to facilitate ease of use for everyday users, rather than that a particular software component was designed exquisitely or that the project fulfills the stated requirements that its originator decided on.

INTRODUCTION

We have now seen the basic tools we will use for the development process in creating mobile applications. The next step is to begin defining a methodology for building real applications and to show the implementation of the methodology in building these real applications.

Through the first four chapters, we discovered that, because of the condition of the mobile user and nature of the mobile application, the mobile application may interface with the user through a variety of devices and channels. In this chapter, we will take a closer look at the fundamentals of user interfaces to software applications, primarily mobile applications. We will focus on changing a paradigm shift in the application developer's thinking, moving him or her from thinking that an application will be used using a mouse, keyboard, and a monitor to thinking that an application may be used by a subset of any system input and output channel through which the user may receive stimuli from a system and respond to it. Finally, we will look at how to create user interfaces in layers so that we apply the principal of separation of concerns to orthogonal aspects of user interfaces. For demonstration purposes, we will use the XForms standard of W3C as an example for an XML-based tool designed to create the proper abstractions in user interface design.

INTRODUCTION

Proper testing and quality control of software has been said to be one of the most neglected areas of software development. Whereas this streamlining of testing and quality control can reduce the budget and the time frame for delivery of projects, the quality of the delivered product is ultimately sacrificed. Although lack of testing and quality control can be the cause of failure, or at least customer dissatisfaction, of many software products, it has been tolerated in the world of PC applications. This is mostly due to the tolerance that the users have to buggy software with stability and functionality issues. However, this tolerance does not exist in the world of mobile application development. Mobile devices are always looked upon, even if they are not, as embedded devices. To the users, there is no difference between a way a PDA, a cell phone, and a VCR should operate: The user interface must be simple and there is zero tolerance for problems relating to security, stability, performance, and all of those other things that these same users have built an immunity toward during the usage of PCs.

INTRODUCTION

We have used the term active transactions in this text only for the lack of a better term that encapsulates the active participation of a computing system in interacting with the user. What we refer to as active transactions in this text includes all those behaviors exhibited by the system that are started autonomously by the application without the immediate and synchronous invocation of the software by the user. A subset of active transactions is often referred to as push-based technologies. Although the term “push” is better used in defining the implementation of the application, one part of the application could “poll” or “pull” and still exhibit active participation in interacting with the user.

What is important to note right away is that active transactions are not limited to push. Let us look at some examples of what we may mean by active transactions:

• An active mobile application that collects end-of-day field results can scan through the records of a salesperson's visits and if he or she has failed to fill out a time sheet with the appropriate visits, the application locates the salesperson by contacting him or her at all pertinent contact points. For example, the application may call the salesperson on the phone and ask him or her to say how many hours were worked and where the work was performed. The salesperson may have simply forgotten to log his or her hours; this process would not only contact the salesperson but also give the salesperson the opportunity to provide the required information during the same session. […]

INTRODUCTION

Security is always one of the biggest concerns when designing any application, but particularly distributed applications. Distributed applications operate over networks, involve multiple users, and have many other properties that make them more vulnerable to security breaches. Though there are stand-alone mobile applications, as we have discussed earlier in this text, most mobile applications, at their core, are distributed applications. Unfortunately, to date, there remain many unsolved problems with security concerns of mobile applications.

Our goal in this chapter will be to first introduce a taxonomy of mobile application security problems, look at few general approaches in solving these problems, and finally review those problems that remain unsolved. Security also tends to be a system-wide problem, not just an application problem, whether dealing with mobile or stationary applications. So, we are not out to show you sample code, standards, or specific techniques; such discussions are completely beyond the scope of our discussion. Our main purpose is to take a step back and look at the big picture of mobile application design and see where security concerns may be. Security is intimately bound to the design of the platform for which the mobile application is being built.

INTRODUCTION

The word replicate means “to produce a copy of itself” and originates from the Latin word replicates. The word synchronize is defined by the Webster dictionary to mean “to represent or arrange (events) to indicate coincidence or coexistence.” Synchronization and replication are two essential operations in distributed computing. Although synchronization can mean a variety of things, replication is typically used in reference to data. Like the literal definitions of synchronization and replication in the English language, their definitions within the field of computing are different but related. In this chapter, we will limit our discussion of synchronization and replication to data synchronization and data replication. As you may have already noted, we used the term synchronization, in Chapter 8, when synchronizing contents and actions transmitted across multiple communication channels. We are discussing synchronization in the context of data replication in this chapter.

Data replication, in its broadest sense, simply refers to copying data from one or more data storage locations to one or more other data storage locations. Note that these locations are virtual locations and not physical locations—it is not required for the virtual locations to be at different physical locations. The taxonomy of the types of replication technologies depends on the domain problem as well as the infrastructure on which replication is being performed. However, we can break nearly all data replication into two groups: complete replication and partial replication.

INTRODUCTION

Because of the depth of the design discussions in this text, we have had little chance of discussing coherent examples of mobile applications as applied to the various techniques introduced. The goal of this chapter will be to create a large fictitious project, based on a real project, define requirements for it, and then build the application using the techniques introduced. Obviously, we will not be able to use all of the techniques that we have discussed; there are far too many in this text. Nonetheless, we will aim at discussing as many as possible in reasonable detail.

The example we will be introducing will be in the field of automation. Namely, we will be creating an application to help an electrical repair crew with a variety of tasks in the field. We will start by working on the requirements, then create an architecture that satisfies the requirements, follow it up with a detailed level design, and work our way into implementation.

REQUIREMENTS DRIVING THE ARCHITECTURE

First, let us understand the basic needs of the customer for which we are building an application. The reader should know that this example is based on the needs of a real company, the Noor Electrical and Engineering Company, located in Costa Mesa, California.

INTRODUCTION

Much of what we have discussed in this text has been focused on design problems and high-level approaches to building mobile applications. We have intentionally stayed away from a more syntactical-driven approach because languages and tools are evolving rapidly in the space of mobile applications. We have looked at a variety of design patterns and architectural solutions that address the problems associated with mobile applications. In this chapter, we are going to take a step back, look at some very high level architectures, and discuss how we should use them in building our mobile applications.

In an abstract manner, a software system is to the domain problem it solves what the solution may be to a math problem. Through the years, mathematicians have refined “canonical” solutions to a wide variety of mathematical problems. “Canonical,” as defined by the Webster dictionary, is an adjective for something “conforming to a general rule or acceptable procedure.” Much of the purpose of various fields of engineering is to define these canonical “best practices and ways” of doing things for given problems. A large part of the field of software engineering involves defining canonical solutions for developing software applications so that every problem in building a software application does not have to be solved from scratch.