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

Corinna Vinschen corinna-cygwin@cygwin.com
Fri Mar 8 15:09:00 GMT 2013

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

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

Thanks for the hint,

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

More information about the Cygwin mailing list