On Thu, 22.07.10 11:31, Simo Sorce (ssorce@xxxxxxxxxx) wrote: > > On Thu, 22 Jul 2010 16:49:50 +0200 > Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > > > 3. Robustness: The sockets stay around all the time, and always > > connectable. You can kill a daemon but you won't lose a single > > connection while doing that! Particularly for stateless protocols > > (such as DNS or syslog) we can automatically restart a daemon when it > > crashes, and when it comes back it will go on where it left of, as if > > nothing happened! The client will not even notice! How awesome is > > that? Restarting daemons without losing connections? > > How many truly statless protocols use a stateful connection ? > > right now if you restart syslog you already don't miss anything, same > for DNS, where is the advantage there ? That's no true. Traditionally, if you stop syslog and then restart it the socket will be closed and removed from the file system. If clients log during that time the log message will be lost because /dev/log is not accessible. And syslog logging is not repeated by the client side if it fails. On DNS this is slightly different, as DNS requests are repeated on failure. But also HTTP is a good candidate. When apache shuts down it closes the listening socket but will finish processing the requests it already began to process. Would apache use socket actviation like this it would hence be restartable without loosing a single HTTP connection: what is already accepted will be processed, but what has not been accepted yet will be delayed until apache is back up again. Something similar is of course true for every state-less protocol like this, where each requests can be processed independently of every other request. And when a daemon crashes only the requests that were currently processed will be lost, all others stay queued and will then be deqeued and processed after the restart. Socket activation does not prevent all kinds of data loss or denial of service when a daemon crashes. However it is actually big step to make the data loss minimal and the outage window as short as possible. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
