Sockets Byte-Ordering Primer

For those who are new to sockets programming or who've long ago forgotten the idiosyncrasies of byte ordering with sockets (as I had when I needed to know this last year), here's a primer on what byte ordering is, why it's needed, and terms such as little-endian, big-endian, network byte order, and host bye order.

The main benefit of the sockets programming interface is that it enables you to communicate with other systems over a network—regardless of their processor or operating system. The sockets programming interface is similar across modern operating systems; as a result, you might end up communicating with machines that interpret and store data in completely incompatible ways. For example, Intel and VAX machines store numeric values in least significant byte first order. This ordering of bytes is known as little-endian because the data is represented "little-end-first." On the other hand, workstations—such as most Unix workstations—store numeric with the most significant byte first—or big-endian for "big-end-first."

As an example, Table 1 shows the differences between representing the decimal value 256 would be seen in the hex display of a debugger in little-endian and big-endian formats.

Table 1—Formatting of the decimal value 256 in little-endian and big-endian.

Format Hex Value
Little-Endian 00 01
Big-Endian 01 00

For example, if you send the number 256 in big-endian format to another system that interprets numbers in little-endian format, the receiving system would misinterpret the number as decimal one instead of decimal 256.

Because of these differences, the Internet Protocol Suite defines two terms—network byte order and host byte order. Network byte order is a format where the most significant byte is first. Host byte order refers to the local machine's byte order. Note that the host byte order could be either little-endian or big-endian, depending on the local machine's processor (Intel, HP, Motorola, etc.) Also, the host order may or may not be the same as the network order. However, if there's the chance that your code could run on a different type of machine than the one you're developing on and to ensure that the data is interpreted correctly, you should always convert from host to network byte order when sending data and from network to host byte order when receiving data.

# # #



About the Author

Tom Archer - MSFT

I am a Program Manager and Content Strategist for the Microsoft MSDN Online team managing the Windows Vista and Visual C++ developer centers. Before being employed at Microsoft, I was awarded MVP status for the Visual C++ product. A 20+ year veteran of programming with various languages - C++, C, Assembler, RPG III/400, PL/I, etc. - I've also written many technical books (Inside C#, Extending MFC Applications with the .NET Framework, Visual C++.NET Bible, etc.) and 100+ online articles.

Comments

  • A few suggestions...

    Posted by nmarler on 03/27/2004 05:23pm

    This is a great topic for an article. Tom might consider incorporating these items: (1) a quick definition of "most significant" and "least significant" bits, (2) explaining that "first", in the context of "little/big-end first", is relative to writing the number from right-to-left (not left-to-right), (3) choose another number, instead of 256, for the example. Translated to hex, 256 is all ones and zeros; something like 43981 might be more instructive. 43981 = 0xABCD which is stored in memory as CD AB

    • Great feedback!

      Posted by Tom Archer on 03/27/2004 07:25pm

      Thanks for the input. I'll definitely consider these ideas when I update the article! Cheers, Tom

      Reply
    Reply
Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • 10 Rules that Make or Break Enterprise App Development Projects In today's app-driven world, application development is a top priority. Even so, 68% of enterprise application delivery projects fail. Designing and building applications that pay for themselves and adapt to future needs is incredibly difficult. Executing one successful project is lucky, but making it a repeatable process and strategic advantage? That's where the money is. With help from our most experienced project leads and software engineers, …

  • Packaged application development teams frequently operate with limited testing environments due to time and labor constraints. By virtualizing the entire application stack, packaged application development teams can deliver business results faster, at higher quality, and with lower risk.

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds