DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=C5dGotZykU/SbpHrJK8cPCZDGwLt95S9S4x0+T95ztcXAMpoEVq5G
	e3W8q85cq/anT/mpqoeXjYB0fEGj2rEjXY3Hf7sCRLsAdyKLOoaY6IvMAnK8g63a
	s7zZz0KtxqP0gykh8fZLlqWKLKci+wYUFlBiiFF1knCfXO2gEA4e0o=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Mon, 8 Apr 2013 19:37:27 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Unix domain accept() and getperrname() doesn't return the client address.
Message-ID: <20130408173727.GF10126@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <CANjopZEy2_yzpPpmxFtqBC_jhHNPyh7MHdeCY-QrizRoYM1_7Q@mail.gmail.com> <20130304093836.GB5468@calimero.vinschen.de> <CANjopZHUZ-Azy+n5P1ZkNJuTb3c3zfj93bGz-pHfWra2aXTfRA@mail.gmail.com> <20130307143712.GA12359@calimero.vinschen.de> <CANjopZG9AiJUJ-8ax5_T=_VFHqHLVSA=2cGwYEH2d10LqEc7Vg@mail.gmail.com> <20130308132937.GA15061@calimero.vinschen.de> <5139F448.4000808@gmail.com> <20130308143715.GD15061@calimero.vinschen.de> <5139F946.1050507@gmail.com> <20130308150855.GE15061@calimero.vinschen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20130308150855.GE15061@calimero.vinschen.de>
User-Agent: Mutt/1.5.21 (2010-09-15)

On Mar  8 16:08, Corinna Vinschen wrote:
> 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.

Or maybe it will.  I just applied a change which creates a funny
filename analoguos to the abstract socket address as described in
Linux' `man 7 unix'(*).  This should help to get a AF_LOCAL datagram
server running.  Please given the next developer's snapshot from
http://cygwin.com/snapshots/ a try.


Corinna

(*) http://linux.die.net/man/7/unix

-- 
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