F21 Self Contained Change: Remote Journal Logging

[Simo Sorce]

On Tue, 2014-04-22 at 20:58 +0200, Miloslav Trmač wrote:
> 2014-04-22 20:19 GMT+02:00 Simo Sorce <simo at redhat.com>:
> 
> > On Tue, 2014-04-22 at 19:04 +0200, Miloslav Trmač wrote:
> > > 2014-04-22 15:10 GMT+02:00 Simo Sorce <simo at redhat.com>:
> > >
> > > > 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.
> > > >
> > >
> > > Isn't that an inherent capability of TCP?
> >
> > Sure, that's one way when bandwidth is the issue. There are other issues
> > though, and just closing the connection on the client if you do not want
> > any traffic is a bit blunt. It also does not give the client any idea
> > when it is ok to retry.
> >
> 
> Not like that—just stop reading from the socket, causing the server to
> advertise a zero-length window to the client.  The client will then know
> that writes are blocking / not being processed.  And when the server has
> more capacity, free up the buffers and the kernel will send a window update
> to the client automatically.

And you keep resources tied this way, it is better to tell the client to
come back later, maybe give it a time when it is ok to come back.

The client can decide what to do, whether to save logs or dump them, or
retry earlier anyway if it is running out of buffer space and some such.

But that is not for me to decide, so I'll stop here.

Simo.

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