Home > Articles > Pick the Network Protocol that’s Right for your Device
Pick the Network Protocol that’s Right for your Device
Jan Axelson
This article originally appeared in Nuts & Volts.
If you have a project that involves putting a device on a local network or the Internet, one decision you’ll need to make is how the device will exchange information on the network. Even for small devices, there are more options than you might think.
A device can host web pages, exchange e-mail and files, and run custom applications that use lower-level Ethernet and Internet protocols.
This article will help you decide which protocol or protocols best suit your application. The focus is on options that are practical for small systems, but the information also applies to PCs that perform monitoring and control functions in networks.
The Basics of Networking Protocols
Computers can use a variety of protocols to exchange information on a network. Each protocol defines a set of rules to perform a portion of the job of getting a message from one computer to the program code that will use the message on the destination computer. For example, the Ethernet protocol defines (among other things) how a computer decides when it’s OK to transmit on the network and how to decide whether to accept or ignore a received Ethernet frame.
Other protocols can work along with Ethernet to make transmissions more efficient
and reliable, to enable communications to travel beyond local networks, and
to provide information that a specific application requires. For example,
every communication on the Internet uses the Internet Protocol (IP) to specify
a destination address on the Internet. Many small systems support these protocols:
| Protocol | Use |
| Internet Protocol (IP) | Communicating on the Internet |
| User Datagram Protocol (UDP) | Specifying a destination port for a message, (optional) error-checking |
| Transmission Control Protocol (TCP) | Specifying a destination port for a message, flow control, error checking |
| Hypertext Transfer Protocol (HTTP) | Requesting and sending web pages |
| Post Office Protocol 3 (POP3) | Requesting e-mail messages |
| Simple Mail Transfer Protocol (SMTP) | Sending e-mail messages |
| File Transfer Protocol (FTP) | Exchanging files |
| File Transfer Protocol (FTP) | Exchanging files |
Multiple networking protocols work together by communicating in a layered structure called a stack. The lowest layer is the Ethernet controller or other hardware that connects to the network. The top layer is the end application, such as a web server that responds to requests for web pages or a program that sends and requests e-mail messages.
These are typical layers in a networking stack:
Not every computer needs to support every protocol. Small devices can conserve resources by supporting only what they need.
The program code (or hardware) that makes up each layer has a defined responsibility. Each layer also knows how to exchange information with the layers directly above and below. But a layer doesn’t have to know anything else about how the other layers do their jobs.
In transmitting, a message travels down the stack from the application layer that creates the message to the network interface that places the message on the network. In receiving, the message travels up the stack from the network interface to the application layer that uses the data in the received message.
The number of layers a message passes through can vary. Within a local network, an application layer may communi¬cate directly with the Ethernet driver. Messages that travel on the Internet must use the Internet Protocol (IP). Messages that use IP can also use the User Datagram Protocol (UDP) or the Transmission Control Protocol (TCP) to add features such as error checking and flow control.
Vendors of development boards with networking abilities often provide libraries or classes to support popular protocols. This support greatly simplifies how much programming you need to do to get something up and running.
Just Ethernet
To communicate over a local Ethernet network, the minimum requirement is program code that knows how to talk with the Ethernet controller. In most cases, the controller is a dedicated chip that interfaces to the network hardware and to the device’s CPU. The controller chip handles much of the work of sending and receiving Ethernet communications.
To send a message, the device’s program code (often called firmware in small devices) typically passes the data to send and a destination address to the controller. The controller places the information in the expected format, adds an error-checking value, sends the message on the network, and makes a status code available to let the CPU know if the transmission succeeded.
In receiving a message, the controller checks the destination address and performs error checking. If the address is a match and no errors are detected, the controller stores the message and uses an interrupt or flag to announce that a message has arrived.
For applications that don’t need much more than Ethernet support, a good resource is the interface boards and program code from EDTP Electronics. (Update: no longer available.) EDTP’s Packet Whacker contains an Ethernet controller, an RJ-45 connector for an Ethernet cable, and a parallel interface for connecting to a microcontroller:
Example code for Microchip’s PICMicros and Atmel’s AVR microcontrollers is available.
See “Easy Ethernet Controller” in the January 2004 Nuts & Volts for more about using the Packet Whacker. Fred Eady’s new book, Networking and Internetworking with Microcontrollers (Newnes) has the most detailed explanation around of how to access Ethernet controllers in small systems.
Using Low-level Internet Protocols
A device that communicates on the Internet must support Internet protocols. Devices in local networks often use Internet protocols as well because they add useful capabilities and have wide support.
The essential protocol for Internet communications is IP, which defines the addressing system that identifies computers on the Internet. Each IP datagram includes addressing information, information for use in routing the datagram, and a data portion that contains the message the source wants to transmit to the destination. In a local network, an IP datagram can travel in the data field of an Ethernet frame.
Many Internet communications also use TCP. An important feature of TCP is support for handshaking that enables the sender to verify that the destination has received a message. TCP also enables the sending computer to provide an error-checking value for the message and to name a port to receive the message on the destination computer. Applications that don’t require TCP’s handshaking may use UDP, a simpler protocol that can be useful for systems with limited resources.
A TCP segment or UDP datagram travels in the data portion of an IP datagram. The data area of the TCP segment or UDP datagram contains the message the source wants to pass to the destination.
To use a PC to communicate with a device using TCP or UDP, you can use just about any programming language. In Visual Basic .NET, you can use the System.Net.Sockets namespace or the UdpClient or TcpClient classes. This example uses the TcpClient class:
' Read data from a remote computer over a TCP connection.
Dim networkStream As networkStream = myTcpClient.GetStream()
If networkStream.CanRead Then
Dim dataReceived(myTcpClient.ReceiveBufferSize) As Byte
' Read the networkStream object into a byte buffer.
' Read can return anything from 0 to numBytesToRead.
' This method blocks until at least one byte is read
' or a receive timeout.
Dim numberOfBytesRead As Integer = networkStream.Read _
(dataReceived,
0,
CInt(myTcpClient.ReceiveBufferSize))
Else
MessageBox.Show("You can't read data from this stream.")
Return
End If
' Write data to a remote computer over a TCP connection.
Dim networkStream As networkStream = myTcpClient.GetStream()
Dim dataToSend(7) As Byte
‘ (Place data to send in the byte array.)
If networkStream.CanWrite Then
networkStream.Write _
(dataToSend,
0,
dataToSend.Length)
Else
MessageBox.Show("You can't write data to this stream.")
End If
Visual Basic 6 supports TCP and UDP communications via the Winsock control.
Serving Interactive Web Pages
One of the most popular ways for computers to share information in networks is via web pages. Many web pages are static, unchanging displays of information, but small devices usually want to serve pages that display real-time information or receive and act on user input.
My article “Control Your Devices from a Web Page” in the March 2004 Nuts & Volts showed one example. I used a Dallas Semiconductor TINI module to serve a page that enables users to monitor and control the device. (Update: the TINI is no longer available.)
Requests for web pages use the Hypertext Transfer Protocol (HTTP). The requests and the responses containing the web pages travel in TCP segments. To serve web pages, a device must support TCP and IP and must know how to respond to received requests.
For creating web pages that display real-time data and respond to user input,
there are several options.
Devices programmed in C often use the Server Side Include (SSI) and Common
Gateway Interface (CGI) protocols. Rabbit Semiconductor’s Dynamic C for
its RabbitCore modules supports both.
Devices programmed in Java can use a servlet engine that enables running Java servlets, which extend a server’s abilities. Two servlet engines for TINIs and other small systems are the Tynamo from Shawn Silverman and TiniHttpServer from Smart SC Consulting.
A third option is to use a product-specific protocol that defines how a device can insert real-time data in web pages and receive user input. Netmedia’s SitePlayer is an example of this approach.
Exchanging Messages via E-mail
E-mail is another option that small devices can use to communicate in networks. E-mail’s original purpose, of course, was to enable humans to exchange messages, but devices can also be programmed to send and receive messages without human intervention.
Just like a person, a device can have its own e-mail account, user name, and password. The device firmware can compose messages to send and process received messages to extract the information inside.
For example, a security system can send a message when an alarm condition occurs. Or a device can receive configuration commands in an e-mail message.
With e-mail, the sender can send a message whenever it wants and recipients can retrieve and read their messages whenever they want. The down side is that recipients may not get information as quickly as needed if they don’t check their e-mail or if a server backs up and delays delivery.
To send and receive e-mails on the Internet, a device must have an Internet connection, an e-mail account that provides access to incoming and outgoing mail servers, and support for TCP/IP and the protocols used by the mail servers to send and retrieve e-mail. Two protocols suitable for small systems are the Simple Mail Transfer Protocol (SMTP) for sending e-mail and the Post Office Protocol Ver¬sion 3 (POP3) for retrieving e-mail.
Exchanging Files with FTP
Devices that store information in files can use the File Transfer Protocol (FTP) to exchange files with remote computers. Every FTP communication is between a server, which stores files and responds to commands from remote computers, and a client, which sends commands that request to send or receive files. A device may function as either a server or client.
To use FTP, a device must support a file system, where blocks of information are stored in named entities called files. In a small device, a file system can be as basic as a structure whose members each store a file name, a starting address in memory, and the length of the file stored at that address.
FTP communications travel in TCP segments. A device that supports FTP must also support TCP and IP.
The Internet Protocol Gets an Upgrade
For a couple of decades, version 4 of Internet Protocol (IPv4) has been the workhorse that has helped get messages to their destinations on the Internet. But version 6 (IPv6) is now making its way into networking components and will eventually replace IPv4. Probably the biggest motivation for change was the need for more IP addresses. But IPv6 has other useful enhancements as well, including support for auto-configuring, the ability to request real-time data transfers, and improved security options.
Where to Find IPv6
In the world of desktop computers, recent versions of Windows, OS X, and
Linux all support IPv6. For microcontrollers, Dallas Semiconductor’s
runtime environment for TINI modules supports IPv6 addressing.
If you don’t need IPv6’s benefits, upgrading isn’t likely to
be required any time soon. For the near future, routers that support IPv6
will continue to support IPv4, converting between protocols as needed.
Increasing the Address Space
IPv6 vastly increases the number of IP addresses available to computers on
the Internet.
An IPv4 address is 32 bits. IPv6 addresses are 128 bits, allowing over 300
sextillion values. Using this many bits may seem like overkill, bit IPv6’s
creators wanted to be very, very sure that the Internet wouldn’t run
out of addresses for a very long time. Having plenty of bits to work with
also makes it easier to create routing domains, which enable a router to store
a value that indicates where to send traffic destined for addresses in a defined
group. Routing domains allow simpler routing tables and more efficient routing
of traffic.
An IPv4 address is usually expressed as four decimal numbers separated by
periods:
192.168.111.1
Each decimal number represents one of the four bytes in the address.
IPv6 addresses are written as 16-bit hexadecimal values separated by colons.
The IPv4 address above translates to this:
0:0:0:0:C0:A8:6F:1
A double colon can replace a series of 16-bit zero values:
::C0:A8:6F:1
(An address can have no more than one double colon.)
It’s also acceptable to express an IPv4 address converted to IPv6 using decimal values instead of hexadecimal:
::192.168.111.1
Other Benefits
Even if you don’t need IPv6’s addressing, other additions to the
protocol can make a switch worthwhile.
Stateless Autoconfiguration frees users and administrators from having to
enter IP addresses manually. A computer can generate its own IP address and
discover the address of a router without requiring a human to enter the information
or requiring the computer to request the information from a server.
Autoconfiguring is especially handy for mobile devices that move around, possibly connecting to a different network each time the device powers up.
IPv6 also adds security features. Two new headers are the Authentication header and the Encapsulating Security Payload (ESP) header. The Authentication header enables a computer to verify who sent a packet, to find out if data was modified in transit, and to protect against replay attacks, where a hacker gains access to a system by capturing and resending packets. The ESP header and trailer provide security for the data payload, including support for encryption.
Every IPv6 header also includes a Flow Label that can help real-time data get to its destination on time. A value in the Flow Label can indicate that a packet is one in a sequence of packets traveling between a source and destination. A source can request priority or other special handling for packets in a flow as they pass through intermediate routers.
To find out more about IPv6, some good sources are: