• C

byte ordering in networks (read, write)

I'm writing a network program that communicates using sockets.

If I am using read / write functions in C programming, do I have to be concerned with byte ordering if I am sending integers, or integer arrays over?

I do know that the due to the byte ordering for different systems that may use little or big endian.  But I also heard that some integer numbers are generally the same whether it's little/big endian.

Any comments?
Who is Participating?
jimmy007Connect With a Mentor Commented:
depends what you carry and on which plattform your application support!!!

software for i386 plattform only or PPC only you don't care. Sender and receiver have the same architecture.

plattform independant:

1 - if you send and read bytes it's OK

2 - if you use word or int then you must use byte ordering macros:

for instance, let's say you have a structure:

typedef struct _test{
    int i1;
    byte b1;
} test;

test data1;
data1.i1 = 0x01020304
data1.b1 = 0x5

if you don't care about byte ordering and you send this information from Intel computer to a MAC then on the other hand you will get:

data1.i1 will be 0x04030201 --> corrupted
data1.b1 remain the same

before seding it you must use: htonl or htons; stand for Host TO Network Long / Host TO Network Short

on reception you use: ntohl or ntohs


htonl(data1.i1) then memcpy to your buffer and write to the created socket.


read the socket, memcpy into the same structure then use ntohl(data1.i1) before using it

I hope this will help you

>>>I'm writing a network program that communicates using sockets.

If you are writing a program to talk to some existing protocol, then you
certainly need to comply with its rfc.
If you are sending data to yourself then you just need to be consistent
from end-to-end.

Most things you send, say through a program like this, may be encoded and
reencoded several times using ASN, BER and PPP.  The transporter, UDP
or TCP, don't care how the individual bytes are arranged or interpreted.

If you are using a stream socket, you can be assured that you will be receiving/sending the information in host byte order (the socket itself will do the conversion from host to network byte order and vice-versa).  You will need to pay a little more attention if you are using raw sockets since you would be bypassing the byte conversion algorithms.  In this case, you should look at the htons (host to network short), htonl, ntohs, and ntohl functions.  These are very useful functions for doing byte order conversions (network byte order is always big endian, so these will only do a conversion if you are on a little endian machine, a nice feature to take advantage of).

If you are concerned about portability between big and little endian platforms, you will need to be especially careful of bitwise comparisons using constants, bitwise shifting, and pretty much any other bitwise comparison.  If you find yourself doing these a lot, it would be wise to force a byte ordering (with htonl or htons), such that the comparisons will be done in the same byte order, regardless of platform.
YamSengAuthor Commented:

I create my socket using
socket(AF_INET, SOCK_STREAM, 0);

Does that means I don't have to care about this byte ordering thing?

But I've got a book here on socket programming, it advises to convert to string before sending over and converting back to the data type at the other end.

The other method is explicitly define the binary formats of the supported datatypes and pass all data between client and server in this format. (similar to RPC)

This book also uses SOCK_STREAM on it's sockets.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.