I need to set up a client server on a Linux system such that the client sends the server data from multiple files. My plan was to write a server daemon that opened up a listening port for clients to connect to and send data. Researching this I see that there is the old way to do this, and the new way using Systemd. I would like to do it in the most current and correct way.
The initial code examples and explanations I found that showed the "old way" made sense to me. They showed forking a new process each time a client connected. Performance is important in this application. Reading the Systemd information, I'm a bit confused as to how to handle multiple clients in a performant way. When I first saw that Accept=yes in the unit file spawned a new service for each incoming connection, I thought this was the equivalent method I should use. However the man page discourages that.
From the SYSTEMD.SOCKET(5) man page: "Accept= Takes a boolean argument. If true, a service instance is spawned for each incoming connection and only the connection socket is passed to it. If false, all listening sockets themselves are passed to the started service unit, and only one service unit is spawned for all connections (also see above). This value is ignored for datagram sockets and FIFOs where a single service unit unconditionally handles all incoming traffic. Defaults to false. For performance reasons, it is recommended to write new daemons only in a way that is suitable for Accept=no."
Does anyone know what the "new way" to write daemons for performance is alluded to here? I have been referencing a couple books in addition to Duck Duck Go ing. Any text recommendations on this topic are also appreciated.
Thanks,
Gene
The "old way" is that systemd runs one copy of your program per connection. Each new connection causes another copy of your program to start, which handles that connection through stdin and stdout. This is inherited from a program called inetd and it makes it easy to write simple internet servers.
The "new way" is to use accept.
The reason to tell systemd to create the socket is that systemd won't start your program until some client actually connects to the socket. If you don't need that feature, there's no need to use systemd to create the socket. Your program can create it itself.