Re: accept(2) call doesn't populate sockaddr struct with connecting address
Re: accept(2) call doesn't populate sockaddr struct with connecting address
- Subject: Re: accept(2) call doesn't populate sockaddr struct with connecting address
- From: Carl Hoefs <email@hidden>
- Date: Fri, 08 Aug 2014 15:48:10 -0700
On Aug 8, 2014, at 1:23 PM, Carl Hoefs <email@hidden> wrote:
>
> On Aug 8, 2014, at 1:17 PM, Josh Graessley <email@hidden> wrote:
>>
>>
>> Before the call to accept, what is user_addr_len set to? How big (and what) is user_address? Have you considered the changes required to support IPv6?
>>
> Yes! Good catch! I forgot to set that field, it was 0, so 0 bytes got written. It now works, thx!
>
> To support IPv6, all I need to do is change over to sockaddr_in6 structs? The other calls still expect sockaddr structs, so I would deed to cast them.
Just to update this, I did convert everything over to IPv6, and it all works.
Question: If my app is listening on an IPv6 socket, and a app connects to it using an IPv4 socket, what happens behind the scenes? In my testing, I cannot distinguish between an IPv4 or IPv6 based socket process that connects, it all looks like IPv6 (sin6_family=AF_INET6). The inet_ntop() function returns the string "::ffff:127.0.0.1" when I connect locally using an IPv4 socket based app. So I'm guessing that there's an automatic upgrade to IPv6 when one of the endpoints is IPv6?
-Carl
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden