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
> >
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
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.
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
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 sup
On Mar 8 09:46, Tanaka Akira wrote:
> 2013/3/7 Corinna Vinschen:
>
> > Not really, no. This is another "nobody asked for it yet", but I think
> > that's a bug. I'll have a look to fix that for 1.7.18. But the above
> > restriction will apply. If we have no peer address, you get a
> > sockaddr
2013/3/7 Corinna Vinschen:
> Not really, no. This is another "nobody asked for it yet", but I think
> that's a bug. I'll have a look to fix that for 1.7.18. But the above
> restriction will apply. If we have no peer address, you get a
> sockaddr_un with empty path.
If a Unix domain datagram s
On Mar 7 22:48, Tanaka Akira wrote:
> 2013/3/4 Corinna Vinschen:
>
> > It's not exactly intentional, but known. The socket's peername is not
> > transmitted during the local socket credential exchange. So far the
> > server assumes an unbound socket on the client side because, well, I
> > guess
2013/3/4 Corinna Vinschen:
> It's not exactly intentional, but known. The socket's peername is not
> transmitted during the local socket credential exchange. So far the
> server assumes an unbound socket on the client side because, well, I
> guess the reason is "nobody asked for it yet". This c
On Mar 4 12:19, Tanaka Akira wrote:
> Hi.
>
> I found that accept() and getperrname() on a Unix domain socket doesn't
> return the client socket address.
> The sun_path field of the returned address is empty.
>
> Is it an intentional behavior?
It's not exactly intentional, but known. The socke
Hi.
I found that accept() and getperrname() on a Unix domain socket doesn't
return the client socket address.
The sun_path field of the returned address is empty.
Is it an intentional behavior?
% uname -srvm
CYGWIN_NT-5.1 1.7.18s(0.263/5/3) 20130301 15:56:19 i686
% ls
tst-client.c tst-server.c
11 matches
Mail list logo
