GNOME Bugzilla – Bug 314624
[PATCH] Provide a way to use unix sockets beside simple tcp sockets
Last modified: 2013-02-13 22:50:38 UTC
The following patch adds support for bith AF_INET and AF_UNIX sockets to tcp{server,client}{sink,src} elements. Of course the elements should be renamed i'm waiting comments about that. I added a socket-type property that can be either GST_TCP_SOCKET_TYPE_INET or GST_TCP_SOCKET_TYPE_UNIX, and modified the "host" property in "address" that can be either an ip/host name for AF_INET protocol, or a path for unix sockets. The socket creation uses the socket type to determine what to do with the property. The "port" property is only useful when using inet socket type, of course.
Created attachment 51397 [details] [review] Unix Sockets Patch Patch against 0.8 branch of CVS
I forgot to mention that if you use a port number of 0, after the connection is made, the port number will be set to the real port number used, so you can do useful stuff with that.
Created attachment 51606 [details] [review] gst-tcp.patch I forgot to add a file to the diff. This one should work
Hi Raphael, This looks like good stuff to have in those elements. However we need the 0.8 elements to remain stable, and don't really have the resources to do development work on that branch any more. After all, 0.10 will be out in less than two months. So if you could rework these elements to use 0.10, there is a much higher chance of these patches getting reviewed and accepted, especially if you do so before the API freezes (including object properties).
No problem for me, just waiting a definitive interface review.
Assigning to thomasvs for review of the property interface
Well considering Thomas is being very lame, let's get some motion on this. Do you still want this in Raphael? If so you will need to make a new patch against 0.10. Since we're stable you can't remove properties, so you'll have to create some kind of parallel interface (i.e. pay attention to address if it's non-null, otherwise use host/port).
I don't *need* this anymore, i just made it optional, using regular tcp sockets for inter-process communication, which is less leet.. Unfortunately i won't be able to work on this before the end of the month because of my exams, i'll see after that what i can do. To keep it simple i could use hos by default, and if address is set, ignore host properties.. There was also the idea of making new elements from this, with complicated hierachies, but this is too much work for me..
No rush. I wouldn't bother making new elements either, just adding a property is best i think. Let us know whenever you get the patch worked up.
Raphael, It would be interesting to have those updated to 0.10. Any updates your side ?
Unfortunately no. I don't have time nor will to do this by myself now. Consider the existing 0.8 patch as a draft patch, and maybe mark this as gnome-love or whatever that you could give out to a new community member wanting to contribute. Porting it to 0.10 will be fairly straightforward i think, and it will be rewarding for him to have his name on the project.
(In reply to comment #11) > Unfortunately no. I don't have time nor will to do this by myself now. > > Consider the existing 0.8 patch as a draft patch, and maybe mark this as > gnome-love or whatever that you could give out to a new community member > wanting to contribute. Porting it to 0.10 will be fairly straightforward i > think, and it will be rewarding for him to have his name on the project. > I'm looking at the gst-plugins-base/gst/tcp/gsttcpclientsink.c in Git and it seems to be only supporting AF_INET address family. I might as well give it a try if there's still interest to get it in HEAD.
I rewrote the patch but haven't been able to successfully transfer data.. can someone suggest proper ways to test and debug this? Currently, I'm trying with a command like this: gst-launch --gst-debug=tcpclientsink:5 fdsrc fd=1 ! tcpclientsink protocol=none socket-type=unix address=/tmp/echo_socket and echoing the data with a server code snippet from: http://www.ecst.csuchico.edu/~beej/guide/ipc/echos.c I'm able to connect to the socket, but data is never received after (reading from stdin).
I don't think this should be added to tcp{client,server}[sink,src}. There should be unix{client,server}{sink,src} that handle this. Unix Domain Sockets are in no way related to TCP (well, except that they both use sockets but you can say the same about UDP) so it should be a separate element. Those elements will probably share a lot of code though.
(In reply to comment #14) > I don't think this should be added to tcp{client,server}[sink,src}. There > should be unix{client,server}{sink,src} that handle this. > > Unix Domain Sockets are in no way related to TCP (well, except that they both > use sockets but you can say the same about UDP) so it should be a separate > element. Those elements will probably share a lot of code though. > Agreed. I think I'll try to write a 'unixclientsink' first, as it seems to be working with the ported 0.8 patch proposal. INET and UNIX domain socket code have quite a lot of common code, but I don't know yet any better way to organise this (e.g. renaming tcp* elements probably is not going to be worth the mess).
Created attachment 140548 [details] [review] Patch proposal for adding Unix domain socket support I've written separate unix{server,client}{sink,src} elements in gst-plugins-base/gst in the Git repo. The draft patch should be attached with this post. To apply it, I do simply: $ cd gst-plugins-base $ git apply gst-unixsockets.patch I used the similar tcp* element code as a template. Here is some notes what has been essentially changed and what's kept: - unixserversink does not inherit multifdsink, but will only send to one client - multifdsink depends too much on TCP-specific code - if multifdsink is needed, fallback to gsttcpserversink? - examples use 'socat' tool as the other end point for the connection - supports raw data transfer and GDP protocol (type of SOCK_STREAM) I'm not entirely sure if the elements are handling broken pipes and closed connections correctly, but the behavior is somewhat similar to the tcp counterparts (shutting down pipeline via error checking). Comments are appreciated and I can make further changes if necessary.
Hm, multiple connections for the serversink would still be nice. unix domain sockets support this too.
Comment on attachment 140548 [details] [review] Patch proposal for adding Unix domain socket support You should try to keep the multifdsink approach of tcpserversink, unix domain sockets support this too. Also, please make a patch against gst-plugins-bad for this, remove the GDP feature (gdppay/gdpdepay should be used instead) and rename the plugin to unixdomainsockets or something like that. unix is too generic
multifdsink would handle unix domain sockets if someone wrote the 2-line patch to make it not error out. What is the use case for adding support for UNIX domain sockets that can't already be handled by localhost TCP sockets? Although AF_UNIX sockets are somewhat faster, if you actually care about the difference (i.e., you're moving GB/sec though a socket), you should be using shared memory. And if you're using a protocol on top of AF_UNIX, you wouldn't want to use a generic unix socket element.
Well, AF_UNIX sockets are easier to handle than shared memory and don't have the overhead of TCP. But you're right, with the shmsrc and shmsink elements in gst-plugins-bad it's not really an important feature anymore, just something that would be nice to have :)
This seems to work fine now with multisocketsink seeing that its unit test does exactly that: http://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/tests/check/elements/multisocketsink.c#n105 Please re-open if it still doesn't work with the reworked elements in git master.