Unix domain accept() and getperrname() doesn't return the client address.
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
> >>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
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin