Unix domain accept() and getperrname() doesn't return the client address.

[Corinna Vinschen]

On Mar  8 16:44, Noel Grandin wrote:
> On 2013-03-08 16:37, Corinna Vinschen wrote:
> >On Mar  8 16:23, Noel Grandin wrote:
> >>On 2013-03-08 15:29, Corinna Vinschen wrote:
> >>>You can call connect on both sides. But ultimately you're right, I
> >>>guess. I never thought about it that way, and it seems nobody used
> >>>AF_LOCAL datagrams so far. Weird. The problem is that the
> >>>underlying protocol is AF_INET because Windows doesn't support
> >>>AF_LOCAL.
> >>If you're using UDP as your underlying protocol, UDP already
> >>contains a port you can reply to.
> >Yes, but the port isn't available to the application which opened a
> >AF_LOCAL connection.  If recvfrom returns an AF_INET name, it's rather
> >tricky to convert it into an AF_LOCAL name for a subsequent sendto call.
> >
> >[...time passes...]
> >
> >Or... are you suggesting that recvfrom returns some kind of fake AF_LOCAL
> >name, which can be converted back to AF_INET by sendto on the fly?
> 
> Yup, sorry, friday afternoon, not being very good with the explaining thing.
> 
> It's obviously a localhost connection, so we only need a way of
> stashing and retrieving the port number, not the host part.

Right.  That sounds like a reasonable workaround.  After all, the sender
shouldn't care for the real filename backing the peer socket, it just
needs something looking like a AF_LOCAL record to address the peer socket
reliably.

I think about it, but this will probably not make it into 1.7.18
anymore.


Thanks for the hint,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple