gethostbyname() confusion

[Björn Giesler]

Hi,

I'm thoroughly baffled. I'm trying to port some network code I wrote
and tested on ix86 (Win, Linux) to big-endian machines (PPC, Sparc),
and it looks like I have no idea about how network / host byte
ordering works. I thought I had...

Problem is as follows: gethostbyname() et al. are supposed to give me
IP addresses in network byte order, which is big endian. Therefore,
for an IP address of 141.3.88.90 (Hex 8d.3.58.5a), I should get an
in_addr_t of 0x8d03585a. But on ix86, I get 0x5a58038d, which is
little-endian, which is host byte order.

What's up with that? Is the documentation wrong (everywhere! Even MSDN
says gethostbyname() returns network byte order!), or am I plain
stupid? Help...

Thanks in advance,
Björn

[Marc Rochkind]

On 23 Jul 2003 09:21:27 -0700, Björn Giesler <bjoern@giesler.de> wrote:

> Hi,
>
> I'm thoroughly baffled. I'm trying to port some network code I wrote
> and tested on ix86 (Win, Linux) to big-endian machines (PPC, Sparc),
> and it looks like I have no idea about how network / host byte
> ordering works. I thought I had...
>
> Problem is as follows: gethostbyname() et al. are supposed to give me
> IP addresses in network byte order, which is big endian. Therefore,
> for an IP address of 141.3.88.90 (Hex 8d.3.58.5a), I should get an
> in_addr_t of 0x8d03585a. But on ix86, I get 0x5a58038d, which is
> little-endian, which is host byte order.
>
> What's up with that? Is the documentation wrong (everywhere! Even MSDN
> says gethostbyname() returns network byte order!), or am I plain
> stupid? Help...
>
> Thanks in advance,
> Björn
>

In network byte order, for an IP of 141.3.88.90, 141 goes in the high-order
byte, and that has the lowest-numbered address. Viewed on a little-endian
machine, the 32-bit number would therefore be 0x5a58038d. For such a number
on an little-endian machine, 8d is the lowest-numbered address, followed by
03, then 58, then 5a. This matches 141.3.88.90 exactly.

Another way to think of it is that what on a big-endian machine would be
the high-order byte (141 = 8d) becomes the low-ordered byte on a little-
endian machine.

Maybe the source of the confusion is this: When you see 0x5a58038d, you are
not seeing a bin-endian number on a big-endian machine. You are seeing a
big-endian number on a little-endian machine.

Or, did I make things worse?

--Marc

[David Schwartz]

"Björn Giesler" <bjoern@giesler.de> wrote in message
news:aedbaeac.0307230821.767db7fd@posting.google.c om...

> Problem is as follows: gethostbyname() et al. are supposed to give me
> IP addresses in network byte order, which is big endian. Therefore,
> for an IP address of 141.3.88.90 (Hex 8d.3.58.5a), I should get an
> in_addr_t of 0x8d03585a. But on ix86, I get 0x5a58038d, which is
> little-endian, which is host byte order.

Okay, let's try to appoach this a few ways:

1) A little-ending machine will always show you numbers in little-endian
form. It can do nothing else. So why are you surprised that an x86 machine
shows you numbers in little-endian form?

2) If the x86 showed you the IP as 0x8d03585a, then it would be showing
it to your *correctly*, which means it must have been in the correct byte
order for the host. Since the x86 is showinh you a number that's in the
wrong byte order, it must display wrong.

3) When you see '0x5A8038D' on a little-endian machine, what do you
think has to be in memory for it to show that? Isn't is 8D, 03, A8, 05?
(That's what little-endian means -- big things are stored in reverse order).
Now look closely at what's in memory: 8D, 03, A8, 05. Isn't that the address
in network byte order?

Do any of these help clear it up?

DS

[Björn Giesler]

Marc Rochkind <rochkind@basepath.com> wrote in message news:<oprsrxtrg8ojfyi9@den.news.speakeasy.net>...

> Maybe the source of the confusion is this: When you see 0x5a58038d, you are
> not seeing a bin-endian number on a big-endian machine. You are seeing a
> big-endian number on a little-endian machine.
>
> Or, did I make things worse?

Well, kinda :-)

You cleared up that I'm looking at the numbers the wrong way by saying
that a printout of 0x5a58038d on little-endian means the same as a
printout of 0x8d03585a on big-endian. Thanks for that. But now, I'm
transferring 0x5a58038d (little-endian) to a big-endian machine (via
CORBA, so the long should stay a long), and I still get 0x5a58038d!

Example code: Say I have a method of some object

in_addr_t getIPAddress()

that does all the casting and ->s_addr'ing for me and returns the
local host's IP address in network byte order, as returned by
gethostbyname(). Now, say that I'm able to call this function both
locally (on little-endian) and via CORBA (on big-endian). Locally, I
get the following:

printf("%s\n", inet_ntoa(obj.getIPAddress()) -> "141.3.88.90"

Remotely, I get the following:

printf("%s\n", inet_ntoa(obj.getIPAddress()) -> "90.88.3.141"

If I'm just looking at numbers the wrong way (as you're implying),
then why does a NBO address, looked up on a LE machine and transferred
to a BE machine but still NBO, get interpreted as LE host byte order?
Where is the byte swap here?

Thanks a lot in advance,
Björn

[Barry Margolin]

In article <aedbaeac.0307231316.1ba06095@posting.google.com >,
Björn Giesler <bjoern@giesler.de> wrote:

>You cleared up that I'm looking at the numbers the wrong way by saying
>that a printout of 0x5a58038d on little-endian means the same as a
>printout of 0x8d03585a on big-endian. Thanks for that. But now, I'm
>transferring 0x5a58038d (little-endian) to a big-endian machine (via
>CORBA, so the long should stay a long), and I still get 0x5a58038d!

CORBA takes care of doing the appropriate translation between
representations on different machines.

Big-endian and little-endian refer to how a number appears when you view it
as a byte array. If you always view it as a long, and your communication
software performs translation (as a good presentation-layer library
should), you never have a problem.

--
Barry Margolin, [email]barry.margolin@level3.com[/email]
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

[Valentin Nechayev]

>>> Bj?rn Giesler wrote:

BrG> I'm thoroughly baffled. I'm trying to port some network code I wrote
BrG> and tested on ix86 (Win, Linux) to big-endian machines (PPC, Sparc),
BrG> and it looks like I have no idea about how network / host byte
BrG> ordering works. I thought I had...

BrG> Problem is as follows: gethostbyname() et al. are supposed to give me
BrG> IP addresses in network byte order, which is big endian. Therefore,
BrG> for an IP address of 141.3.88.90 (Hex 8d.3.58.5a), I should get an
BrG> in_addr_t of 0x8d03585a. But on ix86, I get 0x5a58038d, which is
BrG> little-endian, which is host byte order.

No. You show reversed logic, which is invalid.

BrG> What's up with that? Is the documentation wrong (everywhere! Even MSDN
BrG> says gethostbyname() returns network byte order!), or am I plain
BrG> stupid? Help...

First, see what is in memory not as integer, but as byte sequence.
Network order means it will be: 0x8D 0x03 0x58 0x5A. But, interpretation
of it is different due to different endianness. As big-endian 32-bit integer,
this byte sequence represents 0x8D03585A, and you see it on Sun.
As little-endian 32-bit integer, this byte sequence represents 0x5A58038D,
and you see it on x86.

In case of host order, you'd see 0x8D03585A in both cases, but it will be
written in memory as 0x8D 0x03 0x58 0x5A on Sun, but as 0x5A 0x58 0x03 0x8D
on x86.


-netch-