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_un with empty path. > > If a Unix domain datagram server don't get an address of client, > the server cannot send a reply. > > I think this means Unix domain datagram socket will be much less useful.
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 use stream sockets, you have an accept/connect sequence which can be used to exchange information so that can be easily implemented at one point. For dgram sockets you would have to add the connection information to every datagram. But that's a problem in itself, given that there's a maximum size of a datagram which is reliably transmitted as a single package. Since Cygwin would have to prepend the connection information transparently to every AF_LOCAL datagram, the application wouldn't know about that and would be free to use the maximum datagram size, which raises the danger that datagrams are split. I already had contact with applications which were seriously broken if a datagram was unexpectedly split. 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
