----- Original Message ----- > From: Sascha Cunz <sascha...@babbelbox.org> > Subject: Re: [Development] Qt Playground - Updating Daemon/Service Support > >> All services/daemons must be able to interface with other processes: > Here, I almost agree :-) > >> (a)- a "client-process" can > "request-a-client-operation" to occur on that >> service/daemon > > But this is totally orthogonal to the application being a daemon/service. To > some daemons your application "talks" HTTP, SMTP, mysql-protocol or > whatever > others... > Why would someone writing a cron-alike daemon want to listen on some > QLocalSocket?
Kind of. A daemon/service has two interfaces: (i) user/system-API oriented, and (ii) one internal. The first presents the interface to the outside world on how to control the service. This interface needs to integrated into the system - e.g. Windows Service API, systemd, shell scripting, user query. However, this interface also needs to be able to talk to the daemonized process which has had its user-interface (e.g. Tty) removed from it. You can only do that using some form of communications - network port, message queues, etc. Requiring use of a network port (e.g. TCP XXX, UDP XXX, etc.) seems a little extreme. It also makes for a wider target of remote attacks on applications, not good. Many of the technologies for IPC are very platform specific - e.g. message queues, named events, named pipes, etc. So we would have to rewrite an abstraction layer for that. Or we could use QLocalSocket to allow the outside (i) to talk to the daemonized process (ii), and let Qt do the abstracting for us, likely providing a better, more standarized interface, and expanded comms capability. >> (b)- a process can "query" or "control" the > service/daemon (such as to >> "pause" it, or "stop" it, etc.) > > That is the task of: > - launchctl on Mac > - Service-Manager / "net start" / ServiceControlManager-API on Windows > - Init-Scripts (or interfaces to them) on Linux > [This describtion meats OpenRC, Upstart, systemd and even SysVInit, right?] yes, and we have to implement the interfaces to those. Each of those has a front end interface that must talk via IPC to a daemonized process in some form. Some form of IPC must be used. > Without using those, you blindly bypass any security mechanisms that the OS > itself provides for services/daemons. > I really wouldn't like anybody on my system capable of creating a > QLocalSocket to also be able to stop a service. You don't blindly by-pass it. And not just anyone would be able to necessarily talk to it - it's no different than what's used in QtService<> already. >> Thus, some inter-process communication is always required. > IPC can also be shared-memory or files on disk. This has nothing to do with a > QLocalSocket. Yes. IPC can be a number of things. But as I noted, I'd rather not reinvent the wheel when Qt already has something to offer. Having looked through the QtService code, it creates internal sockets for Windows and Unix, which IIRC are identical to what QLocalSocket uses - a named pipe on Windows, and local socket on Unix. So there is no security difference between using QLocalSocket and what is done by QtService; and its less code for _us_ to maintain for the DaemonApplication API. Ben _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
