Unix Programming - ntoh on ppp and eth connection

This is Interesting: Free IT Magazines  
Home > Archive > Unix Programming > August 2006 > ntoh on ppp and eth connection





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author ntoh on ppp and eth connection
the_edge123.nospam@club-internet.fr

2006-08-30, 7:33 am

Hello,

I was wondering if the behaviour of ntoh is the same on a PPP and an
ETH connection.
I convert an integer with hton(...) and send it from a server socket.
I receive it on a client socket and decode it with ntoh(...).
On ETH, the result is correct but on PPP the value is huge.

Is this behaviour normal ?

Thanks in advance,
Fabien

Nils O. Selåsdal

2006-08-30, 7:33 am

the_edge123.nospam@club-internet.fr wrote:
> Hello,
>
> I was wondering if the behaviour of ntoh is the same on a PPP and an
> ETH connection.
> I convert an integer with hton(...) and send it from a server socket.
> I receive it on a client socket and decode it with ntoh(...).
> On ETH, the result is correct but on PPP the value is huge.
>
> Is this behaviour normal ?

Seems like you have a bug somewhere.

I assume you mean htonl or htons, they work as doumented, and
does not care or know where the integer comes from.
Rainer Temme

2006-08-30, 7:33 am

the_edge123.nospam@club-internet.fr wrote:
> I was wondering if the behaviour of ntoh is the same on a PPP and an
> ETH connection.
> I convert an integer with hton(...) and send it from a server socket.
> I receive it on a client socket and decode it with ntoh(...).
> On ETH, the result is correct but on PPP the value is huge.


Hi Edge_of_Club,

the htonX() ntohX() family does encode data from a host-representation
into a network-representation.

The host-representation is whatever it is (big- or little- endian or
something else), the network-representation is well defined, and the
same for all.

Therefore, the bug is certainly somewhere else ...

Any chance, that the hosts connected via lan (ETH) use the same
internal representation, and the host connected via wan (PPP) does
not?

Are you sure, you already got all data belonging to the item that
you converted with ntoh?() ?

Are you sure it's not an alignment problem? ... this can occur
if you are sending structures ...
(like ... write(fd,&structure,sizeof(structure)); )
the alignment of items can be different on diferent machines ...
therefore converting all items in the structure with htonX()
and then sending it is not good enough.

.... If this doesn't help any further, show the minimal code that
produces the error (sender- and receiver-side)

Rainer
the_edge123.nospam@club-internet.fr

2006-08-30, 7:33 am


Rainer Temme a =E9crit :

> the_edge123.nospam@club-internet.fr wrote:
>
> Hi Edge_of_Club,
>
> the htonX() ntohX() family does encode data from a host-representation
> into a network-representation.
>
> The host-representation is whatever it is (big- or little- endian or
> something else), the network-representation is well defined, and the
> same for all.
>
> Therefore, the bug is certainly somewhere else ...
>
> Any chance, that the hosts connected via lan (ETH) use the same
> internal representation, and the host connected via wan (PPP) does
> not?
>
> Are you sure, you already got all data belonging to the item that
> you converted with ntoh?() ?
>
> Are you sure it's not an alignment problem? ... this can occur
> if you are sending structures ...
> (like ... write(fd,&structure,sizeof(structure)); )
> the alignment of items can be different on diferent machines ...
> therefore converting all items in the structure with htonX()
> and then sending it is not good enough.
>
> ... If this doesn't help any further, show the minimal code that
> produces the error (sender- and receiver-side)
>
> Rainer

I think that the pb comes from a timeout issue. I have to investigate
further.
Thanks for your help

Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com