[Bug 737316] Add support for sending file-descriptors over Unix domain sockets

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=737316
  GStreamer | gstreamer (core) | git

--- Comment #4 from Will Manley <gnome at williammanley.net> 2014-09-25 09:44:12 UTC ---
(In reply to comment #2)
> I think having a GstMeta is the wrong level. The FD should be attached to the
> GstMemory, not the GstBuffer. Maybe as a GInterface on top of the GstAllocator,
> genrallising the interface from GstDmabufAllocator.

Right, so that was my initial approach too, but there is a rather subtle issue
at play.  In my design there *is* a custom allocator, but it lives in a
payloader.  

Imagine that an fdsink receives a buffer with a dmabuf backed GstMemory:

1. How does the sink know that you want the FD sent and not the contents of the
   GstMemory?
2. And if it decides that you want the FD sent it knows what to send as 
   ancillary data, but what should it send as the actual data over the socket?

I believe that the answer to 2 is that you would send a little data that says
something like "I've got a memfd attached, please map from offset to size".  As
soon as you do that I believe that we've invented a new application-layer
network protocol, like RTP, which happens to be transmitted over Unix domain
sockets.  My understanding is that the GStreamer way of handling new formats is
via payloaders/depayloaders rather than custom src/sink types (c.f. RTP).

So if you accept that this is a new protocol, imagine a muxer/payloader:

    gst-launch-1.0 videotestsrc ! memfdpay ! multisocketsink

Upstream of the payloader there are mappable GstMemorys backed with memfds. 
The allocator in memfdpay takes care of that.  This is nice and composable,
like the best of GStreamer.  The upstream elements are oblivious, the pipeline
gets zero-copy for free.  But what do the downstream buffers contain?  The data
that will be written to the socket as before, in this case the header that says
"I've got a memfd attached, please map from offset to size".  In which case how
is the FD passed from the payloader to the sink?  Attached as metadata to the
buffers.

The way I see it is that sockets have in-band and out-of band data, and
GstBuffer also has in-band and out-of-band data: the contents of the memory and
the metadata respectively.  These patches just map the socket-level concepts
into GStreamer.

So this solution has the nice property that you can choose what protocol
(payloader/depayloader/allocator) you want to use separately from choosing how
you want to manage your clients (which sink to use, multisocketsink or fdsink).
 It also has the nice property (that a custom sink wouldn't) that you don't
need to re-implement/duplicate all excellent code in multisocketsink/fdsink for
each fd-passing format.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.