F21 Self Contained Change: Remote Journal Logging
zbyszek at in.waw.pl
Wed Apr 23 02:58:01 UTC 2014
On Tue, Apr 22, 2014 at 03:32:26PM -0400, Simo Sorce wrote:
> 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 amount of resources should be rather insignificant... A few
hundred kilobytes of RSS on the uploader side, and an open socket and
few hundred bytes of local state on the receiver side. Since it's just
one uploader per client, and let's say 1kb per client on the receiver
side, this shouldn't be an issue. The advantage is the simplicify of this
More information about the devel