Posted Aug 17, 2012 6:37 UTC (Fri) by arkaitzj (subscriber, #80462)
Parent article: TCP friends
Shouldn't this fix the problems DBus guys had with unix sockets not having multicast and local TCP sockets being too slow? They don't seem to need to create another socket implementation in the kernel asthey wanted to.
Posted Aug 17, 2012 8:16 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
[Link]
The problem is not in raw bandwidth but in number of context switches. Also, TCP sockets can't be used to pass file descriptors.
TCP friends
Posted Aug 18, 2012 19:58 UTC (Sat) by rvfh (subscriber, #31018)
[Link]
> Also, TCP sockets can't be used to pass file descriptors.
Completely OT, but I would love it if you could explain how to pass fd's through UNIX sockets and why this is not possible with INET sockets :-)
TCP friends
Posted Aug 18, 2012 21:01 UTC (Sat) by viro (subscriber, #7872)
[Link]
man 2 sendmsg
man 2 recvmsg
man 7 unix and see the part about SCM_RIGHTS in there
man 3 cmsg for how to set/parse the ancillary data
as to why it's not possible for AF_INET... it's obviously not going to work between different hosts (we are, in effect, passing pointers to opened struct file instances; descriptors are converted to such pointers on the sending end and pointers are inserted into descriptor table by recepient; resulting descriptor numbers are stored in ancillary data returned to userland). And doing that when both ends are on the same host would result in a headache from hell, since we'd need all garbage-collecting machinery for AF_UNIX to apply to AF_INET as well.