Thread: inet_aton()

The inet_* functions are not very standard. Do you have a testcase we can look at to try to compile it on our systems? My machine says you need to include:

Code:

     #include <sys/types.h>
     #include <sys/socket.h>
     #include <netinet/in.h>
     #include <arpa/inet.h>

to use it. Also, how are you compiling? Perhaps you are using some parameter to gcc that restricts the standard that gcc allows which might disallow various functions from being declared.

You need to serialize the data somehow. Of course whatever API you are using does not understand types and thus can't handle that for you. Using htonl is the simplest form although this does not workout well for more complex protocols.
What protocol are you implementing? Just playing with the API and sending random data?
Here are my suggestions: Define some protocol, You might with to implement the banana protocol, spec available at twistedmatrix.com. Or you might wish to use sexpr.sf.net to send data back and forth with a basic text format. I also suggest not using C for networking. It does not offer any tools that make network programming any easier. I'd suggest using somethign such as common lisp, or python, or erlang (erlang being my preferred choice). These languages take the pain out of serialization for you and offer various tools that are helpful in communicating arbitrary data between two machines. Erlang in particular has a binary data type which simplifies much of the host-to-network translations that are a pain in various languages.

They are not standard like you said, so I guess you need to #define __USE_MISC with Glibc to use the inet_ functions.

I only used it because I read in "Beej's Guide to Network Programming" that it was cleaner to use and was the preferred choice instead of inet_addr or any other function.


I have another question regarding endianness. I've read that the endianness doesn't matter when sending single bytes (i.e. character streams), but what about the bit order? I thought that the bit order is usually the same as the endianness, so wouldn't that screw things up if the receiving side is using a different bit order?

And is there a de facto standard for endianness when sending (any) data through sockets, or is it up to the individual protocols (HTTP, FTP etc) to specify the endianness? I've found that a lot of sources on the internet are contradicting regarding this matter.

Endianess is the byte order of multibyte objects. the order of the bits in a byte are the same throughout machines.
Big endian is the defacto, that's why it's also called network order such as in the function: htonl - host to network long.

Why have I seen sources that claim that the bit order usually follows the endianness then?

Bit order usually follows the same endianness as the byte order for a given computer system. That is, in a big endian system the most significant bit is stored at the lowest bit address; in a little endian system, the least significant bit is stored at the lowest bit address.

Source: http://www.linuxjournal.com/article/6788


As for big endian being de facto, I've also experienced that some server programs sends the data as little endian. Wouldn't it be up to the protocol to define what endianness to use? Or should I just slap the program author for not following the standard?


Another quick question: Will calling htonl() on a big endian machine do anything, or will it actually revert the integer back to little endian?

As the name suggests, htonl converts host endian ot network endian. If these are the same then it does not do anything. network endian does not become little endian just because the host endian is the same.
De facto standards are not an actual standard (that's why they are called de facto). This means that people may choose to do things other ways. Your protocol documentation will state which endianess to use so you just have to follow it.
Note protocols such as http and ftp communicate in plain text so there are no endian issues.

As for your source. I'm not even exactly sure what he is trying to say the language is somewhat unclear. But it's the internet and there is a lot of crap on the internet so I wouldn't take much of it to heart.

This is quite confusing...

So if I have received an integer as little endian, on a big endian machine (with big endian bit order), I can't use htonl to convert it to network endian?

As for the bit order, I'm quite certain that there are different bit orders. A machine could be using little endian byte order, but big endian bit order. htonl would then convert the integer to both big endian byte and bit order (network endianness).

big endian an dlittle endian are byte orders. I have never heard of anything called 'bit order'.
No you can't use htonl to convert it, you'll hav to write your own function to do it.
This is why I suggest using somethign a long the lines of erlang to do this for you, it simplifies things greatly.

A quick google search turned up this document:
http://www.fileformat.info/mirror/egff/ch09_04.htm

Just search for "bit order" within it to see lots of references to different bit orders.

That URL does not work for me.

I actually had a relativly hard time finding anything actually useful on 'bit order' on google. The closest thing I got was that linuxjournal URL you already gave us and alittle exerpt from another place that reads:

Note that within both big-endian and little-endian byte orders, the bits within each byte are big-endian. That is, there is no attempt to be big- or little-endian about the entire bit stream represented by a given number of stored bytes. For example, whether hexadecimal 4F is put in storage first or last with other bytes in a given storage address range, the bit order within the byte will be:

01001111

It is possible to be big-endian or little-endian about the bit order, but CPUs and programs are almost always designed for a big-endian bit order. In data transmission, however, it is possible to have either bit order.

Everything is nice up until the last sentence. But the last sentence confuses the rest of the paragraph I'd say. Obviously it is possible that another machine might send data to you in a different bit order but as the paragraph says, almost all CPU's the same bit order so I wouldn't worry about it. If you do find a machine that sends the bits-in-a-byte in a different order let me know.