Comment 1 by jls@semicomplete.com:

If I patch net/unixgram_posix.go to have ListenUnixgram return a UnixConn, I can call
ReadFrom on it and both a non-zero length and an error are returned.
If the original Go net package is used, ReadFrom on the UDPConn returns zero length and
an error.

Comment 2 by jls@semicomplete.com:

I was able to find a few mailing list threads with no answers. Mostly folks reporting
this problem and others asking for proof. I hope this ticket suffices for proof.
* https://groups.google.com/d/msg/golang-nuts/bRvYw6-9gyU/uLMC6VczGWMJ
* https://groups.google.com/d/msg/golang-nuts/fTh-TzjMtQA/lYggB9M4za8J

Comment 3:

Labels changed: added priority-later, removed priority-triage.

Status changed to Accepted.

Comment 4:

Labels changed: added go1.1maybe.

Comment 5:

I must confess, I have no clue what ListenUnixgram is.
Doc says:
// ListenUnixgram listens for incoming Unix datagram packets addressed to the
// local address laddr.  The returned connection c's ReadFrom
// and WriteTo methods can be used to receive and send UDP
// packets with per-packet addressing.  The network net must be "unixgram".
func ListenUnixgram(net string, laddr *UnixAddr) (*UDPConn, error)
maybe the original API designers intended to make a protocol bridge 
btw UDP and Unix or underlying local file read/write, not sure.
It seems that the latter is already available by FileConn, FileListener 
and FilePacketConn API. The former would be a tough work. So it looks 
this API is a design orphan and perhaps should be obsoleted in the future
release.

Comment 6:

Unix sockets have two kinds: SOCK_STREAM (similar to TCP) and SOCK_DGRAM (similar to
UDP). unixgram is the second kind.

Comment 7:

Hi Remy,
What I don't understand is, how is it possible to make a
following combination.
a) listens for incoming Unix datagram packets addressed 
to the local address laddr.
This happens in Unix domain namespace, perhaps.
b) The returned connection c's ReadFrom and WriteTo 
methods can be used to receive and send UDP packets
with per-packet addressing.
This happens in either UDP domain namespace or Unix
domain space, or both?

Comment 8 by jls@semicomplete.com:

I think my general bug report is best summarized as "cannot use unix datagram sockets in
Go"
Speculating, I believe the "UDP" text in the Unixgram documents are a typo. The problem
isn't the documentation strictly, the problem is the inability to read from unix
datagram sockets - unless there is an alternative api available for this?

Comment 9:

> an alternative api available for this?
I think those ReadFrom/ReadFromUnix/WriteTo/WriteToUnix 
methods UnixConn might be alternatives. Please take a look 
at tip, net/packetconn_test.go and net/protoconn_test.go 
describe simple use cases.

Comment 10 by jls@semicomplete.com:

Summarizing: UnixConn doesn't work because it tries to connect(2).  ListenUnix doesn't
work because it tries to listen(2). ListenUnixgram doesn't work because it provides a
UDPConn which, on ReadFrom() rejects Unix address families and there is no
UDPConn.ReadFromUnix() 
UnixConn from DialUnix doesn't work for reading unixgram data, as 'DialUnix' tries to
connect, which is not correct for 'reading' datagrams from a unix domain socket -
strace output:
[pid  5847] socket(PF_FILE, SOCK_DGRAM, 0) = 3
[pid  5847] connect(3, {sa_family=AF_FILE, sun_path="/tmp/example.sock"}, 20) = -1
ECONNREFUSED (Connection refused)
on the flipside, net.ListenUnixgram does the correct thing:
[pid  6312] socket(PF_FILE, SOCK_DGRAM, 0) = 3
[pid  6312] bind(3, {sa_family=AF_FILE, sun_path="/tmp/example.sock"}, 20) = 0
It's just that you can't read from it due to assumptions of address families (likely due
to ListenUnixgram returning a UDPCon).
ListenUnix gives a UnixListener which requires you call AcceptUnix(), which fails
because that calls listen(2) which fails on unix datagram sockets:
[pid  7652] socket(PF_FILE, SOCK_DGRAM, 0) = 3
[pid  7652] bind(3, {sa_family=AF_FILE, sun_path="/tmp/example.sock"}, 20) = 0
[pid  7652] listen(3, 128)              = -1 EOPNOTSUPP (Operation not supported)

Comment 11:

Hi jls,
Thanks for your comments #10.
I can't say "not correct" because that's user's choice; named unix 
domain sockets or unnamed unix domain sockets.
It looks like current net/unixsock stuff supports named unix domain 
sockets only, unfortunately. So please file a new issue related to your 
comment #10; you need an unmaed unix domain socket or whatever.
Also feel free to send a patch because I'm not a right person to fix u
nix domain socket stuff.
<http://golang.org/doc/contribute.html>;
So let's focus on wrt ListenUnixgram here, whether it's typo or not.
Thanks.

Comment 12:

http://code.google.com/p/go/source/detail?r=fb7e8abcdca09f3dec65701bb8b3a929c72d0c9d&path=/src/pkg/net/unixsock.go

Comment 13:

This issue was closed by revision 0d19725.

Status changed to Fixed.