AF_UNIX + SOCK_DGRAM

[James T. Dennis]

 I was playing with the socket module and Unix domain sockets,
 trying to make it work with SOCK_DGRAM.  I could get messages
 recvfrom() but any attempt to send responses was failing, 
 complaining about the return address.

 Now I think I understand the problem.  The recvfrom() tuple
 does contain two parts (which WOULD BE address and data in UDP)
 but I'm guessing that the address is meaningless for Unix 
 domain sockets.  It occurs to me that the "return" address 
 must be the same socket (filesystem node of type 's') as the 
 one that I did a .bind() to.  

 That suggests that using a Unix domain socket as a bidirectional
 DATAGRAM communications channel requires that we implement a flow 
 control protocol to force the other end to do its recvfrom().
 I honestly know now what happens when more than two processes 
 get involved and I'm curious what the value being returned as
 u.recvfrom()[1] actually means.
 
 This is academic curiosity, and I'll read through the C sources
 to see what I can glean therefrom, eventually.  I'd like to know
 how I can tell what process has opened a connection to my 
 AF_UNIX socket and I'd love to know how to pass an open file
 descriptor through an AF_UNIX socket (in Python).  I've read that
 this is possible in C and that it is one of the few features of 
 AF_UNIX sockets which is NOT available via other address/protocol 
 families.  I've also heard that this can be used as a way for a
 client to request read-only or append-only access to a file
 --- since the UNIX APIs (in C) apparently offer ways for the server
 to obtain credential information about the requesting process as
 well as passing open file descriptors (which are then roughly akin
 to "capabilities" since their access mode can't be changed)