TCP/IP Software: A Buyer’s Guide
TCP/IP is the critical communications link between an embedded system and the rest of the world. It makes sense to choose TCP/IP software wisely.
By Christopher D. Leidigh
Editor's note: We've planned, as a follow-up to this Buyer's Guide, a
product review of the protocol stacks covered here. Be sure
to check
back here for this expanded coverage, scheduled to appear in the
late-June timeframe.
The incredible expansion of both the Internet and the attached intranets has solidified transmission control protocol (TCP)/Internet protocol (IP)’s position as the world’s primary communications protocol. In the mid 1970s, the TCP/IP suite of
networking protocols was developed out of research funded and driven by the US Department of Defense’s Advanced Research Projects Agency (ARPA). The first forms of TCP/IP were used in the ARPANET, one of the first packet-switched networks in the US. The ARPANET grew into a network that connected research institutions, universities, and military sites. By 1985, involvement by the National Science Foundation (NSF) helped create access hubs around the various US supercomputing sites. These access hubs
evolved into the NSFNET and spurred the rapid growth of connections to the network. In 1986, there were an estimated 20,000 computers connected to the Internet (as it had become known by then) and the growth rate was nearly 15% per month. TCP/IP can be found in over 43 million computers (the approximate number of Internet hosts today according to one estimate), something that sets it apart from any other protocol. Novell’s internetwork packet exchange (IPX)/sequenced packet exchange (SPX) is now encapsulated
into TCP/IP, allowing it to be carried across the Internet. Protocols conforming to the International Standards Organization’s (ISO’s) Reference Model for Open Systems Interconnect (the ISO Model) are only marginally found in European networks. Other protocols, such as systems network architecture (SNA), are relegated to mainframe rooms. All of these facts testify to TCP/IP’s success as a flexible, extendable communications protocol base.
TCP/IP’s potential for connecting so many
computers and devices is only in its infancy. To be connected is to speak TCP/IP.
Traditionally, computers, routers, and shared devices such as printers were the only products that implemented TCP/IP networking. Now, there is a wide variety of both device types and connection media that utilize TCP/IP. The disparate nature of such devices, especially the small size and low cost of some, has placed new demands on TCP/IP stack vendors.
This buyer’s guide will help you understand some of the issues
involved in choosing a TCP/IP protocol stack. The guide focuses on vendors that offer source code licenses to base TCP/IP implementations for embedded systems. It also discusses some of the typical application-layer protocols used.
Some background
The protocol suite occupies the middle five layers of the seven-layer OSI model. The TCP/IP layering scheme combines several of the ISO layers (there is little need for their differentiation as shown in
Figure 1
). From an implementation standpoint, the TCP/IP stack encapsulates the network layer (Layer 3 in the OSI model) and the transport layer (Layer 4 in the OSI model). The physical layer, the data-link layer (Layers 1 and 2, respectively), and the application layer (Layer 7) at the top can be considered nonTCP/IP-specific. Indeed, TCP/IP can be adapted to many different physical media types. The actual specifications for TCP/IP are embodied in hundreds of documents, called requests for comment (RFCs),
a carry-over from the early days of the Internet Control and Configuration Board (ICCB). While the BSD UNIX TCP/IP implementations serve as a fairly good reference model, a standard TCP/IP implementation does not actually exist. To complicate matters, RFCs frequently define behavior or specifications using language such as “will implement,” “should implement,” and “may implement” — all of which lead to a wide array of interpretations.
The basic TCP/IP architecture
Figure 2
shows the relationship between the major protocols in the TCP/IP protocol family, or suite.
IP is the base protocol for the suite. This protocol operates at the network layer (Layer 3) in the OSI model, and is responsible for encapsulating all upper layer transport and application protocols. The IP network layer incorporates the necessary elements for addressing and subnetting (dividing the network into subnets), which enables TCP/IP packets
to be routed across networks to their destination. At a parallel level, the address resolution protocol (ARP) serves as a helper protocol, mapping physical layer addresses — typically referred to as media access control (MAC)-layer addresses — to network-layer (IP) addresses.
There are two transport-layer protocols above IP: the user datagram protocol (UDP) and TCP. These transport protocols provide delivery services. UDP is a connectionless delivery transport protocol. It is used for
message-based traffic where sessions are unnecessary. TCP is a connection-based protocol that employs sessions for ongoing data exchange. File transfer protocol (FTP) and Telnet (the remote login protocol) are examples of applications that utilize TCP sessions for their transport. TCP also provides the reliability of having all packets acknowledged and sequenced. Should data be dropped, or arrive out of sequence, the stack’s TCP layer will retransmit and resequence. UDP is an unreliable service, and has no
such provisions. Applications such as the simple mail transport protocol (SMTP) and the hypertext transfer protocol (HTTP) utilize transport protocols to encapsulate their information and/or connections. To enable like applications to speak to one another, TCP/IP has what are called “well-known port numbers.” These ports are used as subaddresses within packets to identify exactly which service or protocol a packet is destined for on a particular host.
Selecting a stack
While choosing
a TCP/IP protocol stack might seem academic, it is easy to overlook the stack’s importance in a system. TCP/IP serves as a conduit to and from devices, enabling the sharing, monitoring, or controlling of those devices. Ideally, TCP/IP stacks would be encapsulated behind a well-defined interface, and the user or developer would only deal with application-level details. A TCP/IP stack can have a tremendous effect on a device’s memory resources and CPU utilization. Interactions with other parts
of the system may be highly undesirable and unpredictable. Problems in TCP/IP stacks can render a system inoperable. The TCP/IP stack becomes a fairly integrated part of a product. The monetary investment for licenses, and the development time for porting, integrating, and testing can be substantial. Suffice it to say, a protocol stack is not something you want to worry about or change; you want to invest wisely.
The first step in choosing a stack is determining the requirements for your system. Some of
the major considerations include (see product table at the end of the article for a vendor by vendor listing):
- Processor type
- Real-time operating system (RTOS) type
- Network interface type
- Base protocols required
- Application layers required
- Protocol interfaces required (such as Berkeley sockets, direct, and low-level raw)
- ROM and RAM limitations (target or maximum available).
Most protocol stack vendors will probably have good RTOS support, meaning that they
will provide an interface between a given RTOS and their stack. In general, an RTOS is necessary for providing timer and task switching services to the stack. In some cases, the stack vendors might also provide a simple round-robin scheduler or a more sophisticated preemptive kernel. Vendors have licensed an RTOS, such as µC/OS, in other instances.
It is important to consider network device driver support when choosing a protocol stack. Most network device design choices will be made based on
hardware requirements or price/performance targets. This usually means finding a stack that supports the chosen device. Although most vendors will provide example drivers and documentation to write a driver for any device, writing a good device driver can still be difficult. Depending on prior experience in this area, this might be a consideration in choosing a stack.
While the TCP/IP stack forms the core of a communication system, it exists to support the multitude of application protocols that perform
actual tasks in a system. Some vendors will provide several common higher-layer protocols, such as Telnet, FTP, the trivial file transfer protocol (TFTP), and SMTP as add-on products to their stack. Other vendors may concentrate on only one or two application protocols, such as the simple network management protocol (SNMP) or HTTP. Choosing to obtain these adjunct protocols from either the stack vendor or a separate vendor involves several considerations. A TCP/IP stack vendor will have already integrated the
application protocols they sell with their stack. While this alleviates the interface work on your part, it does not always provide the best product. Some stack vendors may throw less-than-perfect applications into their product listing, just to have the extra bullet on a feature list. While using a separate vendor’s code is no guarantee of success, doing so ensures a primary product rather than a side product.
Different devices will require different levels of TCP/IP stack customization and will
place different demands on the stack. Because most products are continuously expanded over time, it is critical to have a stack that provides flexibility in its feature set, good documentation, and code comments. It is not uncommon to make custom additions or changes to a stack at various levels. Examples include various startup options for obtaining network configurations. A stack that is well-documented and architecturally clean will facilitate changes throughout the levels. Stacks with different interface
layer options will also be more flexible. Although most application layers only need a Berkeley socket-style application program interface (API), other raw and lower-level interfaces can also be useful. The socket API is the most common method of providing application access to TCP sessions, listening server setup, and datagram transmission and reception. Raw interfaces allow the user to construct packets with more control over all aspects of their content and at different layers. Some user applications
may need this control for proprietary protocol support.
Number games
Unfortunately, there are some number games to be played when it comes to code size. While no one promises that their stack fits into a 4-kbyte footprint, there is some stretching of the truth out there. Code size can vary quite a bit from processor to processor, and depends on which protocols are included in the size specifications. If a vendor is touting support for a particular processor/compiler pair, they should be able
to provide a fairly accurate figure for code size. They should also be able to offer a memory-map listing, showing the different module sizes for the target processor. If the vendor states that they support a particular processor/compiler combination, they should have reference builds for testing. Be aware of optimizations, data widths, and other elements that can affect code size.
Narrowing the selection down to one product requires more effort than evaluating vendors for basic requirements. Since source
code licenses can cost tens of thousands of dollars, the stack can be a major nonrecurring engineering expense (NRE). Just as one looks closely at a house purchase and does a thorough inspection before making a commitment, so too should the stack buyer. While few vendors will permit evaluation of their stack code, most should offer to set up a meeting to demonstrate their product. If they have reference platforms for a PC or a similar environment then they should be able to compile and link the reference.
It is critical to meet with the vendor and technical support staff, and have a look at the product.
Making the extra effort to meet with a vendor can save costs in startup time and may prevent the purchase of a stack that does not meet expectations. A couple of afternoons working with a vendor’s code can go a long way towards securing an understanding of the vendor’s products.
While well-organized and well-documented code does not guarantee bug-free operation, it does say that the vendor
is serious and somewhat organized about their code development. Also, with well-documented code, it is much easier to debug within the stack or make additions.
One problem facing vendors of portable codes such as TCP/IP stacks is how to support multiple RTOS device drivers and processors. This can lead to what I’ll call “ifdefimania.” Code that is inundated with compiler conditional definition statements (IFDEFs) can be difficult to follow. The requirements of the stacks usually dictate
some use of IFDEFs, but beware of IFDEFs with names that look like customer names. If the vendor is submitting code they’ve received from another client or if they’ve created a custom patch that ends up in the shipping source code, they aren’t doing the job themselves. Another concern is how their applications integrate with the stack. Does the code fit in logically and cleanly? Does the code look like it has had the same level of effort applied to it? Or is it just a quickly whipped-up piece
of code that looks like a public domain source code downloaded from the Internet to add to the feature list?
For the base stack port, many vendors have reference builds that will compile and run on x86 DOS systems, using an open data-link interface (ODI) or packet drivers. These reference builds familiarize the build process, the make files, and the use of the stack. Starting with such a system can ensure a good head start on a project; debugging certain aspects of both the build process and the
porting task can be done more easily with this as a first step. Working with the vendor to understand how to bring in the particular application layers and RTOS will facilitate these processes.
Another feature that some stacks offer is a simple loopback setup. This setup focuses on the build and RTOS interface first, and still allows testing of the stack’s operation. Instead of wrestling with the build, processor, RTOS port, and device driver interface simultaneously, a loopback device driver verifies
that it is possible to send and receive packets up and down the stack. The device driver interface can be one of the trickier portions of the porting task, and this loopback setup can break the porting process up into more manageable parts.
The next level of issues concern more subtle features and performance points. They are more difficult to compare and evaluate than the basic issues. As far as second-tier features are concerned, a list below points out some of the more common and interesting things to
look for:
-
Stack configuration
. Every stack has configuration options — some will be defined at compile time, others defined upon stack startup, and still others dynamically changed during runtime. Dynamically configurable options offer more flexibility, but at the cost of simplicity and/or reliability. Options that affect memory usage (such as the number of sockets that can be supported simultaneously, device driver buffer allocation, and task stack size) are typically set at compile
time, although some stacks will enable more dynamic allocation of sockets. Options that define how a device obtains network address configuration are very important. While this tends to be more of a runtime application issue that may involve bootstrap protocol (BOOTP), dynamic host configuration protocol (DHCP), or reverse address resolution protocol (RARP), how the vendor has structured the use of these options is important. Stacks that enable the use of more than one of these options at runtime are
valuable in systems that want to offer flexibility to the user. A related issue is how the stack operates when it doesn’t yet have configuration information about the network. It may be relevant to the operation of the rest of the system that the stack works cleanly and deterministically.
-
Tunable behavior options
. Many aspects of TCP/IP-based communications can be adjusted on a link-by-link or socket-by-socket basis. Vendors have taken different approaches to these elements. Some vendors allow
TCP timing parameters to be configured dynamically when a socket is opened, while others will require that global defaults be set at compile time. The benefit of a high degree of configurability will depend on the particular application. Nonstandard link types such as satellite links can be improved with such tuning options.
-
Performance enhancements
. Comparing stack performance between vendors requires a vast amount of experimentation on different hardware platforms. A legitimate comparison
must include different RTOS architectures. Stack vendors will state that their stacks are high performance and there is little opportunity to prove them otherwise, let alone inter-compare. Investigating the stack architecture (for example, looking at the number of context switches required for typical sending or receiving operations) is one important area. Another area is the use of critical sections, where interrupts are disabled. Critical sections can affect overall system performance if used too frequently.
While most stacks should have provisions for zero-copy buffering (not copying buffers within the stack, but passing pointers as necessary), some stacks may employ more sophisticated techniques to optimize throughput. Designs that do header prediction or tree lookups on port numbers may edge out implementations that traverse link lists. Measuring performance outside of the actual full system is next to impossible. Any vendor claims about throughput or design enhancements should be discussed in terms of
their applicability to a specific system.
-
Code option granularity
. For those concerned about code size, it is important to have a high degree of granularity at compile time to bring in or exclude parts of the stack that may or may not be necessary to a particular application. It is important to discover just how configurable the stack is, and what space savings might be expected when excluding certain parts of the stack.
-
Hardware and software reference platforms
. As mentioned earlier,
reference platforms can be a tremendous help when bringing up a system for the first time, and for testing new components that might be added later. Many vendors are providing various ways to decrease development time by offering such systems. Some vendors even have various embedded hardware platforms — typically, single board computers (SBCs). These can be useful in cases where an organization’s hardware development lags behind the firmware team’s ability to start coding.
Decision
time
The most important thing a developer can do is to take the time to do the research. Developers should familiarize themselves with the various protocols and their basic operation.
Christopher D. Leidigh manages the embedded networking group at American Power Conversion in Providence, RI and is a contributing editor to
Communication Systems Design
. He received his BS in bioelectrical engineering from Brown University. He can be reached at cleidigh@apcc.com.
| Resources
|
Resources
- Comer, D., Internetworking with TCP/IP, Volume I: Principles, Protocols and Architecture, Prentice Hall, NJ, 1995.
- Stevens, W.R., TCP/IP Illustrated, Volume I: The Protocols, Addison-Wesley, Reading, MA, 1994.
|
Puzzled by a network processing design issue?
