You are not logged in.
Pages: 1
Howdy! I was rolling around an idea in this small head of mine to write a daemon. I would really like to write it in either Python or Ruby. My question is: is there a standard way that Linux developers write daemons so that other processes can communicate with them? I have looked into the idea of using something like pyro for RPC; is that an accepted use of an RPC technology like that?
Most of my programming experience is in Windows / .NET world and Rails. I know there are nice ways to grab ahold of windows services with .NET and talk to them. I am wondering how people do it in the Linux (Daemon) world.
Offline
Howdy! I was rolling around an idea in this small head of mine to write a daemon. I would really like to write it in either Python or Ruby. My question is: is there a standard way that Linux developers write daemons so that other processes can communicate with them? I have looked into the idea of using something like pyro for RPC; is that an accepted use of an RPC technology like that?
Most of my programming experience is in Windows / .NET world and Rails. I know there are nice ways to grab ahold of windows services with .NET and talk to them. I am wondering how people do it in the Linux (Daemon) world.
For local access, just use dbus. For remote call, there is no such standard on linux; however you could try CORBA (industry standard, compatible with .net remoting and j2ee's)
BTW I dont think it's good to write daemon in python or ruby - how can you kill or renice it, or even find it on top/ps?
Offline
Good question. What are most daemons written in? I was thinking a scripting language b/c they are super easy to write. I was also thinking about just doing a XML-RPC style "service" to handle requests.
Offline
The Art of Unix Programming has a great chapter on IPC, as does Advanced Linux Programming. Read both.
Most daemons are written in C to reduce resource consumption (and because C is The Unix Language).
I have a ruby script running right now, so I ran ps. It shows up as ruby (the interpreter), not under its own name.
Offline
For CORBA omniORB is complete enough supporting both C++ and Python (if you need I'll post PKGBUILD for it), XML-RPC should also be fine. But the main point is what level of abstraction are you interested in? CORBA is at the highset level for sure and provides abstraction that hides both the underlying connectivity protocol and location of the object. Going down you'll end up with sockets, message queues, shared memory, signals and stuff like this, all described in books mentioned in earlier post. The daemon word can be interpreted in many ways
Offline
Pages: 1