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@xxxxxxxxxx>: > > > > > On Tue, 2014-04-22 at 19:04 +0200, Miloslav Trmač wrote: > > > > 2014-04-22 15:10 GMT+02:00 Simo Sorce <simo@xxxxxxxxxx>: > > > > > > > > > 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 solution. Zbyszek -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
