An overview of networking

A group of interconnected computers is a network. Over time, networking has grown from something that was once available only to governments and large organizations to the almost ubiquitous and truly amazing internet. Though the concept is simple—allow computers to communicate—networking does involve some advanced technology. We won't get into great detail here, though we will cover the core tenets as a background to the general networking we will do in the remainder of this chapter.

6.1.1 Networking basics

A large percentage of the time the APIs you will use to program Android applications will abstract the underlying network details. This is good. The APIs and the network protocols themselves are designed so that you can focus on your application and not worry about routing and reliable packet delivery and so on.

Nevertheless, it helps to have some understanding of the way a network works so that you can better design and troubleshoot your applications. To that end, here we are going to blaze through some general networking concepts, with a Transmission Control Protocol/Internet Protocol (TCP/IP) bent. We will begin with nodes, layers, and protocols. NODES

The basic idea behind a network is that data is sent between connected devices with particular addresses. Connections can be made over wire, over radio waves, and so on. Each addressed device is known as a node. A node can be a mainframe, a PC, a fancy toaster, or any other device with a network stack and connectivity, such as an Android-enabled handheld. LAYERS AND PROTOCOLS

Protocols are a predefined and agreed-upon set of rules for communication. Protocols are often layered on top of one another because they handle different levels of responsibility. For example, in the TCP/IP stack, which is used for the majority of web traffic of all kinds and with Android, the main layers are:

■ The Link Layer (including physical device address resolution protocols such as ARP and RARP and more)

■ The Internet Layer (including IP itself, which has multiple versions, and the ping protocol, ICMP, among others)

■ The Transport Layer (where different types of delivery protocols such as TCP and UDP are found)

■ The Application Layer (which includes familiar protocols such as HTTP, FTP, SMTP, IMAP, POP, DNS, SSH, and SOAP)

Layers are an abstraction of the different levels of a network protocol stack. The lowest level, the Link Layer, is concerned with physical devices and physical addresses. The next level, the Internet Layer, is concerned with addressing and general data details. After that, the Transport Layer is concerned with delivery details. And, finally, the top-level Application Layer protocols, which make use of the stack beneath them, are application specific for sending files or email or viewing web pages. IP

IP is in charge of the addressing system and delivering data in small chunks known as packets. Packets, known in IP terms as datagrams, define how much data can go in each chunk, where the boundaries for payload versus header information are, and the like. IP addresses tell where each packet is from (its source) and where it's going (its destination).

IP addresses come in different sizes depending on the version of the protocol being used, but by far the most common at present is the 32-bit address. 32-bit IP addresses (IPv4) are typically written using a decimal notation that separates the 32 bits into four sections, each representing 8 bits (an octet), such as 74.125.45.100.

Certain IP address classes have special roles and meaning. For example, 127 always identifies a loopback or local address on every machine; this class does not communicate with any other devices (it can be used internally, on a single machine only). Addresses that begin with 10 or 192 are not routable, meaning they can communicate with other devices on the same local network segment but cannot connect to other segments. Every address on a particular network segment must be unique or collisions may occur and it gets ugly.

The routing of packets on an IP network—how packets traverse the network and go from one segment to another—is handled by routers. Routers speak to each other using IP addresses and other IP-related information. TCP AND UDP

TCP and UDP are different types of delivery protocols that are commonly used with TCP / IP. TCP is reliable, and UDP is fire and forget. What does this mean? It means that TCP includes extra data to guarantee the order of packets and to send back an acknowledgment once a packet is received (the common analogy is certified mail: the sender gets a receipt that shows the letter was delivered and signed for and therefore knows the recipient got the message). UDP, on the other hand, doesn't provide any ordering or acknowledgment (it's more like a regular letter: it's cheaper and faster to send, but you basically hope the recipient gets it—you don't know for sure). APPLICATION PROTOCOLS

Once a packet is sent and delivered, an application takes over. To send an email message, for example, SMTP defines a rigorous set of procedures that have to take place. You have to say hello in a particular way and introduce yourself; then you have to supply from and to information, followed by a message body in a particular format. Similarly, HTTP defines the set of rules for the internet—which methods are allowed (GET, POST, PUT, DELETE) and how the overall request/response system works between a client and a server.

When working with Android, and Java-related APIs in general, you won't typically need to delve into the details of any of the lower-level protocols, but you may need to know the major differences we have outlined here for troubleshooting, and you will need to be well versed in IP addressing. In addition, you should also know a bit more about clients and servers and how connections are established using ports.

6.1.2 Clients and servers

Anyone who has ever used a web browser is familiar with the client/server computing model. Data, in one format or another, is stored on a centralized, powerful server. Clients then connect to that server using a designated protocol (such as HTTP) to retrieve the data and work with it.

This pattern is of course much older than the web, and it has been applied for everything from completely dumb terminals connecting to mainframes to modern desktop applications that connect to a server for only a portion of their purpose (such as with iTunes, which is primarily a media organizer and player but also has a store where customers can connect to the server to get new content). In any case, the concept is the same: the client makes a type of request to the server and the server responds. This is the same model that the majority of Android applications, at least those that use a server side at all, generally follow (Android applications typically end up as the client).

In order to handle many client requests, often for different purposes, coming in nearly simultaneously to a single IP address, modern server operating systems use the concept of ports. Ports are not physical; they are simply a representation of a particular area of the computer's memory. A server can "listen" on multiple designated ports at a single address; for example, one port for sending email, one port for web traffic, two ports for file transfer, and so on. Every computer with an IP address also supports a range of thousands of ports to enable multiple "conversations" to happen at the same time.

Ports are divided into three ranges:

■ Well Known Ports—0 through 1023

■ Registered Ports—1024 through 49151

■ Dynamic and/or Private Ports—49152 through 65535

The Well Known Ports are all published and are just that, well known. HTTP is port 80 (and HTTP Secure, or HTTPS, is port 443), FTP is ports 20 (control) and 21 (data), SSH is port 22, SMTP is port 25, and so on.

Beyond the Well Known Ports, the Registered Ports are still controlled and published but for more specific purposes. Often these ports are used for a particular application or company; for example, MySQL is port 3306 (by default). For a complete list of Well Known and Registered Ports, see the ICANN port-numbers document: http://www.iana.org/assignments/port-numbers.

The Dynamic or Private Ports are intentionally unregistered because they are used by the TCP/IP stack to facilitate communication. These ports are dynamically registered on each computer and used in the conversation. Dynamic port 49500, for example, might be used to handle sending a request to a web server and dealing with the response. Once the conversation is over, the port is reclaimed and can be reused, locally, for any other data transfer.

Clients and servers therefore communicate as nodes with addresses, using ports, on a network that supports various protocols. The protocols involved with Android are based on the IP network the platform is designed to participate in and involve the TCP/IP family. Before we can build a full-on client/server Android application using the network, we need to handle the prerequisite task of determining the state of the connection.

6.2 Checking the network status

Android provides a host of utilities to determine the device configuration and the status of various services, including the network. You will typically use the ConnectivityManager class to determine whether there is network connectivity and to get notifications of network changes. Listing 6.1, a portion of the main Activity in the NetworkExplorer application, demonstrates basic usage of the ConnectivityManager.

Listing 6.1 The onStart method of the NetworkExplorer main Activity

@Override public void onStart () { super.onStart() ;

ConnectivityManager cMgr = (ConnectivityManager) this .getSystemService (Context. CONNECTIVITY_SERVICE) NetworkInfo netInfo = cMgr.getActiveNetworkInfo(); this.status.setText(netInfo.toString() ) ;

Obtain manager from Context

NetworkInfo

This short and sweet example shows that you can get a handle to the ConnectivityManager through the context's getSystemService method by passing the CONNECTIVITY_SERVICE constant O. Once you have the manager, you can obtain network information via the NetworkInfo object C. The toString method of the NetworkInfo object returns the output shown in figure 6.2.

Of course you won't normally just display the String output from NetworkInfo, but this does give you a quick glance at what is available. More often you will use the isAvailable or isConnected methods (which return a boolean value), or you will directly query the NetworkInfo.State using the getState method. NetworkInfo.State is an enum that defines the coarse state of the connection, the possible values are: CONNECTED, CONNECTING, DISCONNECTED, and DISCONNECTING. The NetworkInfo object also provides access to more detailed information but you won't normally need more than the basic state (unless of course you have a special use case, such as if you are writing a network state management application).

Once you know that you are connected, either via mobile or Wi-Fi, you can use the IP network. For the purposes of our NetworkExplorer application, we are going to start with the most rudimentary IP connection, a raw socket, and work our way up to HTTP and web services.

Status Output:

NetworkInfo: type: MOBILE, state: CONNECTED/CONNECTED, reason: (unspecified), extra: internet, fall aver: false, IsAvailable: true

Figure 6.2 The output of the NetworkInfo toString method.

+1 0

Post a comment