F21 Self Contained Change: Remote Journal Logging

[Simo Sorce]

On Wed, 2014-04-23 at 05:36 +0200, Lennart Poettering wrote:
> On Tue, 22.04.14 09:10, Simo Sorce (simo at redhat.com) wrote:
> 
> > > I am pretty sure that a pull model should be the default for everything
> > > we do, and push only be done where realtimish behaviour is desired to do
> > > live debugging or suchlike.
> > > 
> > > I am pretty sure the push model concept is one of the major weaknesses
> > > of the BSD syslog protocol.
> > 
> > Except that the server may not need direct access to the clients (in
> > NATted LANs for examples), so sometimes push is all you can count on,
> > make sure you can think how to properly rate limit, give feedback to
> > clients if necessary. A good protocol would allow to send a first small
> > packet that establish a connection and a reply that can "push back" on
> > the client w/o requiring huge bandwidth to be spent.
> 
> Well, you can always turn the NAT problem around. Sometimes it's the log
> server behind the NAT that is the problem, sometimes it it is the log
> client behind the NAT that is the pronlem. If you consider push vs. pull
> then you simply reverse which one is the bigger issue.

Nope, 1 server means you can do port forwarding on the NAT to the
specific server, all clients connect to the same NAT address port and
their connection is forwarded to the server, because it is 1.

The reverse would require to manually map 1 port per client.

Big difference.

> Note that the journal protocol is HTTP, so it's probably as proxy and
> NAT-friendly as it gets.

I already commented how bad an idea it is to use HTTP in the other
thread.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York