You are not logged in.
i thought about creating a distributed channel mechanism like irc which is flexible in creation and usage of those channels
for example to enter a channel it should be easy as opening a file using open() thus also a bash script can use this mechanism
reading/writing equally should work through read()/write()
to dynamically create such channels only by opening a file i think i would need FUSE or are there any other linux mainstream supported possibilities?
well an alternative would be to (un)register on a separate main channel which is only available on localhost which then creates the corresponding channel files
but i want to "use" such channel by using plain simple file api cause it would be easier for shell scripts and very easy adaptable for every language
the question is:
is it possible to create a full duplex IPC like AF_UNIX sockets but with the possibility to use file API instead of socket API?
i came upon udev and dbus which seem to have similarities but another point of view:
udev is a userspace daemon which creates /dev files but depending on kernel notification (like inserting an usb device) - in my case my daemon would need to notify udev to create new /dev/channels/... files whose communication runs over my daemon again
well i dont know if this would be possible using udev?
dbus seems to be a message bus like my idea of channels but its bound to local communication and more complicated to use, cause one needs libdbus
thx for all your suggestions
Bash already does something similar... Check out "man bash" and search for
"/dev/tcp" and "/dev/udp"... Used with the "<>" redirection operator (or ">" followed
by a dup "<&" on a second FD), that should give you a bidirectional stream...
Of course, that's just a raw TCP/UDP connection; no protocol handling, like it sounds
like you want...
One simple way you could do it would be to use a named pipe (FIFO)... You'd have
a daemon reading from that pipe, and clients would write requests to it... After the
initial request, you'd probably need to give each client their own separate named
pipe that you'd create on the fly; actually, two: one for input and one for output...
Then, you'd just forward all data coming in from the pipe to the socket, and all data
coming in from the socket to the other pipe (after performing any higher-level protocol
massaging that you might want)... A bit ugly and klugey, but it could probably work...
Or, you could just invoke the client via a cover app that sets up the connection and
exec*()'s into the client, passing it the socket as stdin/stdout/stderr (or some other
specified FD)... If ongoing protocol management is needed (ie: you don't want the
clients to have to speak raw IRC or whatever), then you probably can't avoid some
kind of relaying daemon, which you'll really have to connect to somehow...