Unix Programming - struct sockaddr

Author

struct sockaddr_XYZ formats portable?

Malte Starostik

2005-06-02, 3:59 am

Hi,

is the layout of the sockaddr_XYZ structs standardised? i.e. is it safe
to send a sockaddr_in and sockaddr_in6 (prefixed with the respective
size) over the wire or do I need to send its individual members?

TIA,
Malte

vishal

2005-06-02, 9:02 am

Firstly, A sockaddr_in structure is just a typecasting for the opaque
sockaddr structure. You can even define your own sockaddr_xyz, as long
as your kernel supports that address family. The reason for the
typecasting is to allow you to access different memory locations
relative to the base address of the particular sockaddr structure,
through the use of the sockaddr_xyz's structure members.

Secondly, you don't send sockaddr_xyz structures over the wire. The
sockaddr_xyz structures are just socket interfaces to the kernel and
are used for passing address/port information to one another. Example -
in the bind() system call, you request some address/port to be assigned
to your server (where it would receive packets). The sockaddr
structure doesn't go anywhere outside your host. When you do a
connect(), the tcp/ip stack (in kernel) takes the address/port of
server where you want to connect (or send DGRAM packet to) and
constructs/sends a corresponding IP header for it. Again, the
sockaddr_in or sockaddr structure is not sent over the network, rather
the information contained in the sockaddr structure is used for
constructing/sending an appropriate packet.

If however, for some reasons, you want to send a particular
sockaddr_xyz structure over to some other hosts on the network, it
would be treated simply as data/payload and there won't be any issues
as long as you maintain byte ordering on both ends.

Now, I'm not very sure about IPv6 addresses, but I believe that while
the socket system calls allow typecasting of sockaddr_in6 structs to
sockaddr, there is a storage limitation to sockaddr{}. Thus, instead of
typecasting a sockaddr{} to sockaddr_in6 *, one should typecast
sockaddr_storage{} to sockaddr_in6 *, which when passed to socket
calls, should be typecasted to sockaddr *.

HTH,
vishal

Barry Margolin

2005-06-02, 9:02 am

In article <1117695956.122774.283810@z14g2000cwz.googlegroups.com>,
"vishal" <vishal.ag@gmail.com> wrote:

> If however, for some reasons, you want to send a particular
> sockaddr_xyz structure over to some other hosts on the network, it
> would be treated simply as data/payload and there won't be any issues
> as long as you maintain byte ordering on both ends.

But what if the recipient's sockaddr_xyz structure has different
members, or they're in a different order, than those on the sender?
E.g. on my system, the sockaddr_in structure is:

struct sockaddr_in {
u_char sin_len;
u_char sin_family;
u_short sin_port;
struct in_addr sin_addr;
char sin_zero[8];
};

but on the recipient's system it could easily be:

struct sockaddr_in {
u_char sin_len;
u_char sin_family;
struct in_addr sin_addr;
u_short sin_port;
char sin_zero[8];
};

I think that's the essence of the OP's question: are these structure
layouts standard?

Actually, even if they are, I don't think you can depend on being able
to send them over the wire. C allows for padding between structure
members, and different C implementations may pad the structures
differently.

If you want to send one of these over the network, you should use
something like XDR to define your own structures and ensure
compatibility.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Malte Starostik

2005-06-02, 3:58 pm

Barry Margolin schrieb:
> In article <1117695956.122774.283810@z14g2000cwz.googlegroups.com>,
> "vishal" <vishal.ag@gmail.com> wrote:
>

Byte order isn't the problem as the multi-byte members like port are
explicitly in "network" order already. Thanks anyway for your
elaborate response.
[color=darkred]
> But what if the recipient's sockaddr_xyz structure has different
> members, or they're in a different order, than those on the sender?
> E.g. on my system, the sockaddr_in structure is:
>
> struct sockaddr_in {
> u_char sin_len;

Alright, neither Linux nor Windows have a sin_len member, so there we
go already ...

> u_char sin_family;
> u_short sin_port;
> struct in_addr sin_addr;
> char sin_zero[8];
> };
>
> but on the recipient's system it could easily be:

[snip different layout example]

> I think that's the essence of the OP's question: are these structure
> layouts standard?

Exactly that was my question. I did a quick check on Linux and Windows
and saw that member sizes, order and overall struct sizes were equal so
I thought maybe they are standardised.

> Actually, even if they are, I don't think you can depend on being able
> to send them over the wire. C allows for padding between structure
> members, and different C implementations may pad the structures
> differently.

And forgot about this one. Indeed the systems I checked on are both
x86, so no surprise the padding is the same. And on a closer look no
explicit alignment is specified in the headers.

> If you want to send one of these over the network, you should use
> something like XDR to define your own structures and ensure
> compatibility.

I'll definately have to use something like that then. Reason I wanted
to avoid that is that the class encapsulating endpoint addresses
currently only exposes the raw data cast to const sockaddr* as that's
all I need for bind(), connect() and sendto() - internally it's a
sockaddr_storage and thus large enough for both protocol families. And
in order to exchange <family, ip, port> tuples with other nodes using
the struct as given seemed easiest since extracting members would be
the first time to introduce explicit handling of IPv4 vs. IPv6 into the
app and protocol.

Cheers,
Malte

Sponsored Links