Unix Domain Sockets

For a very long time I have had it in mind that Puppy needs a more formal way of doing InterProcess Communication (IPC). I have thought about it over the years, ways in which it would be useful, and ways in which it could be implemented, but nothing ever happened.

I did at one time work on a daemon named 'pup_event_backend_d' and I had a vague idea that it could be a kind of server for interprocess communication, including making some of the tray applets that currently use polling technique, more efficient. Also, some utilities that use files in /tmp for message passing and synchronization could also become more professional if they use an IPC technique.

My current iteration of thinking about this has actually got to the stage of conceptualizing how it could all fit together, and as part of this I investigated various IPC methods available in Linux and their merits and demerits.

One interesting IPC method is kernel-dbus, but that is sometime off before it gets merged into the kernel. I did play with a D-Bus server-client, but decided that other techniques are more efficient, and besides I would still like to be able to build a Puppy (ex: Wary) without D-Bus.

I narrowed it down to Unix Domain Sockets, named pipes (fifos) or System V message queues.

I decided to go for Unix Domain Sockets, one reason being that unlike pipes they are bidirectional, and secondly I already have some familiarity of the C functions -- as I have done some coding for Netlink sockets, which use many of the same functions.

Here is a very good intro page on Unix Domain Sockets:
http://beej.us/guide/bgipc/output/html/multipage/unixsock.html

...I have been playing with the example programs from that link.

I must emphasise that this is just playing around at this stage. I might decide not to take it any further.
I'll post about any further developments.

Note, the pup_event_backend_d structure that I have been thinking about, would have both a Netlink Socket and a Unix Domain Socket. Clients will be able to request and receive relevant preprocessed kernel uevent information.
I have tentatively mapped out how such a program will be coded.

For information about the C functions:
http://www.gnu.org/software/libc/manual/html_node/Function-Index.html

---

Comments

Puppy is in need of standardized IPC


interconnect
Username: aarf
""* A custom-built interconnection network, which routes data across the system" if its good enough for the current fastest computer in the world should be ok for puppy i guess. we'll leave the deciphering to you :) more at http://puppylinux.info/topic/so-one-assumes-that-the-os-isnt-linux-or-windoze

Message Passing
Username: Nathan F
"This is a very interesting subject, and I'm glad it drew my attention to the proposed kernel implementation (which I previously didn't know about and just used my google-fu to research a bit). The kernel implementation intrigues me quite a bit. I'd really like to see what form it takes. Also, based on the way Linux development tends to proceed, I'd caution against relying on any present system, or even writing one of your own, with this in the works. The kernel implementation, even though it's way-off right now, is likely to be the standard model if it ever reaches production status. When that happens everything else is likely to become obsolete overnight. Coming from a BSD perspective what seems to always happen is this. A shiny new feature gets introduced that is specific to the Linux kernel. Since the bulk of development for the open source desktop biosphere happens via Redhat and Canonical (really, the bulk of it does), they go full bore into the new technology without any regard for backwards compatibility or portability to another OS. It happened with Alsa, Hald function being moved into Udev, and now it's happening with Systemd. I can see it happening with the message bus too. Anyway, since history seems to always repeat itself here I'd hate to see Puppy development get too locked into a certain model and then have that model become obsolete overnight. The Unix sockets may be a way to go, because that functionality is likely not going anywhere. But I'd stay away from Dbus, because even though they -say- the new framework will be compatible (via a userspace library) I tend to have my doubts.

IPC-puppy taking shape
Username: BarryK
"I have been more than just playing with the idea of using Unix Domain Sockets, I have written a complete daemon, named pup_event_backend_d, with pup_event_frontend_d one of its clients. I have also documented the user interface: http://distro.ibiblio.org/quirky/test/experimental/pup_event_backend-README.htm However, this is some-way-away from appearing in an actual Puppy, as there are problems. The most fundamental problem, I discovered, is that the Linux implementation of Unix Domain Sockets seems to be a bit wobbly. The send() function is documented to return an error if the connection (with client) is broken, however it crashes, and brings the server (pup_event_backend_d) down with it. I have not been able to find out a way to test if a socket connection to client if valid. Online docs indicate that getpeername() should do it, however on Linux this function returns "Success" regardless -- it would seem that it has not been implemented to support local sockets. Reading posts on forums and mail-lists, when someone posts about a Unix Domain Socket problem, many of the replies go on about networking -- as many people do not seem to be aware that this class of socket is local only. I might have to completely rewrite the server with individual processes for each client connection, so if one goes down, the rest won't. Anyway, I'll rest tonight, watch a bit of TV -- "The Dome" is on tonight. If this stuff ever does see the "light of day", it will probably be in Quirky.

Named pipes
Username: BarryK
"I am rewriting it using named pipes. Looking good so far. They are a bot more efficient, plus I think basically more robust. Quite simple also. I'll take down that pup_event_backend user-interface web page, as I will rework it, if decide to go for named pipes.

Inotify directory
Username: technosaurus
"I had almost exactly this same thought process and finally settled on inotify watching a directory. With inotify you can run a (separate) process when any file in the directory is created, removed, modified, read, written, etc... Which can include named pipes, sockets or even devices or directories. as long as you plan to stick with linux, it is quite robust since it uses the inotify syscall as an essentially free event trigger that eliminates polling and the associated cpu usage (bsd has a similar mechanism) The major advantage though is that intermediate devs can work with it from shell scripts just by echoing data to a file in the watched directory.

Re inotify
Username: BarryK
"technosaurus, That is a very good idea! I got IPC working with Unix Domain Sockets, but with some issues. Then yesterday I reimplemented it with named pipes, but have some other issues. Neither solution was as light-weight as I wanted. A very good learning experience anyway.

Under the dome
Username: BarryK
" [i]Anyway, I'll rest tonight, watch a bit of TV -- "The Dome" is on tonight.[/i] That should be "Under the dome"! It is based on a book by Stephen King. Set in a typical US small town -- with murderers, drug-runners and corrupt officials :happy:

yes job well done
Username: aarf
"yes you deserve a rest. Raring Puppy 5.6.94 is good job indeed. but for the life of me i cant see how/why you would find this dome thing, as you describe it, interesting. (scratches head, screws up brow) lol

Tags: woof