Networking allows your embedded device to communicate with other network-embedded devices or computers on the network to coordinate or control activities and/or transfer events or data. As a subject, networking technology is vast and complex, involving hundreds of physical and logical approaches covering a wide-range of applications. The opportunity for network-embedded applications is just now beginning to explode with the introduction of new technologies, fields, and initiatives such as radio frequency identification (RFID), near-field communications (NFC), wireless sensor networks, body sensor networks, Internet zero (I0), wireless personal area networks (WPAN), ultra-wide band (UWB), ZigBee, and WiBree.
|More Info|| |
You can find links to these and many other networking concepts and technologies on the companion Web site for this book: http://www.dotnetmicroframework.com/.
Fortunately, networking technology can be structurally decomposed into a set of architectural layers most commonly represented by the familiar Open Systems Interconnection Basic Reference Model (or simply OSI model), depicted in Figure 6-1. This model allows us to focus on individual aspects of the overall problem of communicating between network nodes within a common framework using a common set of terms, units, and reference points.
Figure 6-1: Standard OSI model.
As you might expect, there are dozens, if not hundreds, of technologies that have been created at each one of the layers shown in Figure 6-1. Using such a hierarchically partitioned approach, it is possible to mix-and-match technologies to achieve the goals of the application, as long as the intralayer interfaces are well defined and adhered to. There are also common collections of technologies (referred to as protocol suites) designed specifically to work together to solve a particular problem. Not all layers will necessarily be used in all suites, because it is often possible to collapse the functionality from multiple layers into a single layer, or it might be the case that technical circumstances do not require or permit certain mechanisms.
The .NET Micro Framework provides support for one of the most ubiquitous of these, the Internet Protocol suite. This includes the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP). Taken together, this collection is generally referred to as TCP/IP.
The .NET Micro Framework will continue to evolve and provide support for a variety of networking technologies as more hardware vendors offer them. For this reason, the OSI model was chosen, even though it is an imperfect generalization of more specific models such as the TCP/IP model.
Placing this back into the context of the OSI model, let us examine each layer of the model as it relates to the .NET Micro Framework, including the purpose of each and what technology variations and implications there are.
Starting at the bottom and working our way up, one of the most important decisions to make when developing a network-embedded device is how it will be physically connected to the network. Layer 1, the physical layer, is responsible for modulating the signal (that is, moving the bits) across some medium, generally either a solid connection (for example, electrical wires or optical cables) or air (by using, for example, radio frequency (RF) or optical transmission). The most relevant of the commonly available technologies at this level are likely to be the Ethernet physical layer (10BASE-T or 100BASE-TX) or the WiFi physical layer (the RF portions of the Institute of Electrical and Electronics Engineers, Inc., or IEEE, 802.11b/g specifications). Other possibilities at this layer include IEEE 802.15.4 (the radio layer used by ZigBee) and Bluetooth. This layer, as its name implies, is supported almost entirely by hardware.
Generally, you will be selecting a .NET Micro Framework device that provides the type of connectivity you require for your application, such as Digi's ConnectME device which provides Ethernet based TCP/IP. The hardware vendor will have taken care of the implementation details required by the .NET Micro Framework runtime, allowing you to focus on the networking problems at a much higher layer in the stack, such as connecting and sending your application data between network nodes.
Layer 2, the data-link layer, drives the physical layer, typically by framing the data (that is, grouping it into blocks of a specific size) to be sent or as it is received and providing physical device addressing. It is also responsible for managing the physical addressing schemes, such as the media access control (MAC). The details of this layer vary widely depending on the protocol and the physical-layer requirements, and the only exposure provided by the .NET Micro Framework is to the physical address in the IP suite. MAC addresses and access to them are described in detail in the section titled "Network Interfaces" later in this chapter.
Layer 3, the network layer, is generally, but not always, the first to be implemented in software and is variously responsible for routing, segmentation and desegmentation, flow control, quality of service, and reporting of delivery errors. As frames of data are received from the data layer, the network layer inspects them to determine whether the information has arrived at its destination address. If so, the network layer processes each frame into packets that it passes on to the transport layer. If not, the network layer modifies the frame and passes it back to the data layer. The protocol that is responsible for this is the so-called "raw" Internet Protocol (IP), which provides a best-effort delivery process and does not guarantee arrival order. A number of configuration options are exposed by the .NET Micro Framework as "socket options," described in detail in the section titled "Socket Options" later in this chapter.
In Layer 4, the transport layer, you will begin to have significant control over the operation of the network. This is primarily where TCP and UDP, the two network protocols currently supported by the .NET Micro Framework, reside. The transport layer is the first essentially logical layer in the stack in that it is concerned with moving data between endpoints rather than with the mechanics of addressing and routing, or of driving the actual transmission medium.
The UDP provides very little functionality over the underlying (raw) IP packet processing and inherits all of its qualities (for example, unreliable, out-of-sequence arrival). The UDP is discussed in detail in the section titled "UDP" later in this chapter, along with how to use it in your programs.
The TCP also operates primarily at this level and provides reliable, connection-oriented, flow-controlled communication between two endpoints. Likewise, it is discussed in depth in the section titled "TCP" later in this chapter, along with extensive coverage of the .NET Micro Framework support for it.
As its name implies, Layer 5 is the session layer, concerned with establishing and maintaining sessions between network endpoints, usually clients and servers (described later). The sockets application programming interface (API), described in the section "TCP/IP Programming with Sockets" later in this chapter, is the most notable representative of this layer, because it abstracts the details for interacting with and controlling the lower four layers through the notion of connected sockets. Similar to physical sockets (electrical outlets, plumbing joints, and so on), this abstraction allows you to think about connecting and disconnecting endpoints. Once connected, data can flow. In a sense, connections can be thought of as sessions because they are established, used, kept alive, and closed when done; thus, they maintain state.
Layer 6, the presentation layer, is responsible for transforming information coming from or going over the network into expected formats, shielding applications from such details. For example, it is at this layer that encryption and compression generally take place.
Network applications use Layer 7, the application layer, to send and receive data over the network. This is where any high-level protocol operates and is distinct from an actual application. Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), and Simple Mail Transfer Protocol (SMTP) are all examples of application-level protocols that are used by applications such as Web browsers, file browsers, and mail clients. In the section titled "The Flashlight Configuration Protocol" later in this chapter, we will develop our own (trivial) application protocol that our client and server will use to communicate with one another. You are likely to invest the most time at this layer.