Project Home
Project Home		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
Networking/Discussion/Technology/sockaddr_in/List of Posts
Forum Topic - sockaddr_in: (5 Items)
   
Update
Mario Charest
09/05/2008 8:57 AM
post12907
sockaddr_in   
Is the layout and size of the sockaddr_in some sort of standard.  

We bought the source for adriver that implement a communication protocol.  In this protocol the sockaddr_in is sent as 
had into the stream.  One of the requirement of this protocol is the endianess of sin_family.    The code does 
sin_familly = htnos ( AF_INET ).  On QNX this breaks because sin_familly is a char.  I checked on other OSes and in all 
of them sin_familly is a short.

Is the maker of that driver wrong to assume the layout of sockaddr_in?
Sean Boudreau(deleted)
09/05/2008 10:41 AM
post12929
Re: sockaddr_in   
On Fri, Sep 05, 2008 at 08:57:35AM -0400, Mario Charest wrote:
> Is the layout and size of the sockaddr_in some sort of standard.  
> 
> We bought the source for adriver that implement a communication protocol.  In this protocol the sockaddr_in is sent as
 had into the stream.  One of the requirement of this protocol is the endianess of sin_family.    The code does 
> sin_familly = htnos ( AF_INET ).  On QNX this breaks because sin_familly is a char.  I checked on other OSes and in 
all of them sin_familly is a short.
> 
> Is the maker of that driver wrong to assume the layout of sockaddr_in?

POSIX says it's an unsigned int so uint8_t is confirmant.
I checked linux and *BSD.  On linux it's an unsigned short
and on the BSD's it's a uint8_t.  I think on linux it's
supposed to be in host order as this field doesn't go out
on the wire so the htons is probably a bug.  Is the driver
being brought over from a big endian environment?

-seanb
Mario Charest
09/10/2008 9:46 AM
post13148
Re: sockaddr_in   
> On Fri, Sep 05, 2008 at 08:57:35AM -0400, Mario Charest wrote:
> > Is the layout and size of the sockaddr_in some sort of standard.  
> > 
> > We bought the source for adriver that implement a communication protocol.  
> In this protocol the sockaddr_in is sent as had into the stream.  One of the 
> requirement of this protocol is the endianess of sin_family.    The code does 
> 
> > sin_familly = htnos ( AF_INET ).  On QNX this breaks because sin_familly is 
> a char.  I checked on other OSes and in all of them sin_familly is a short.
> > 
> > Is the maker of that driver wrong to assume the layout of sockaddr_in?
> 
> POSIX says it's an unsigned int so uint8_t is confirmant.
> I checked linux and *BSD.  On linux it's an unsigned short
> and on the BSD's it's a uint8_t.  I think on linux it's
> supposed to be in host order as this field doesn't go out
> on the wire so the htons is probably a bug.  Is the driver
> being brought over from a big endian environment?

No but the protocol requires a sockaddr_in like structure to be send over the wire and it must be big endian.  Maybe the
 protocol comes from a big endian environment that I don't know.

> 
> -seanb
Sean Boudreau(deleted)
09/10/2008 10:47 AM
post13156
Re: sockaddr_in   
> > On Fri, Sep 05, 2008 at 08:57:35AM -0400, Mario Charest wrote:

> No but the protocol requires a sockaddr_in like structure to be send over the 
> wire and it must be big endian.  Maybe the protocol comes from a big endian 

If that's the case the protocol should define a
private struct, not use sockaddr_in.  I'd assumed
you were talking about a sockaddr_in being passed
to bind(), connect() etc in which case I bet the htons()
would break on little endian linux.

-seanb
Mario Charest
09/10/2008 1:52 PM
post13185
Re: sockaddr_in   
> > > On Fri, Sep 05, 2008 at 08:57:35AM -0400, Mario Charest wrote:
> 
> > No but the protocol requires a sockaddr_in like structure to be send over 
> the 
> > wire and it must be big endian.  Maybe the protocol comes from a big endian 
> 
> 
> If that's the case the protocol should define a
> private struct, not use sockaddr_in.  I'd assumed
> you were talking about a sockaddr_in being passed
> to bind(), connect() etc in which case I bet the htons()
> would break on little endian linux.

The make of that driver agreed their code is broken and will use their own private flavor of sockaddr_in.

Thanks!

> 
> -seanb
>

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems