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.


  • 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

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

Top White Papers and Webcasts

  • Live Event Date: December 11, 2014 @ 1:00 p.m. ET / 10:00 a.m. PT Market pressures to move more quickly and develop innovative applications are forcing organizations to rethink how they develop and release applications. The combination of public clouds and physical back-end infrastructures are a means to get applications out faster. However, these hybrid solutions complicate DevOps adoption, with application delivery pipelines that span across complex hybrid cloud and non-cloud environments. Check out this …

  • On-demand Event Event Date: October 29, 2014 It's well understood how critical version control is for code. However, its importance to DevOps isn't always recognized. The 2014 DevOps Survey of Practice shows that one of the key predictors of DevOps success is putting all production environment artifacts into version control. In this webcast, Gene Kim discusses these survey findings and shares woeful tales of artifact management gone wrong! Gene also shares examples of how high-performing DevOps …

Most Popular Programming Stories

More for Developers

RSS Feeds