Re: [Nbd] another?

[Alex Bligh <alex@...872...>]

--On 16 September 2011 13:35:06 +0200 Wouter Verhelst <w@...112...> wrote:

> No, I think this should be fixed in the server, not the tester client.
> This is a condition that the server needs to be able to deal with. The
> fact that it doesn't is a bug in the server which the tester client only
> exposed, it's not a bug in the tester client. If anything, it's a
> feature of the tester client that it exposes a bug in the server.

Amusing as it is for this to be a 'it's my bug not your bug' discussion
(the other way around from normal), I think it *is* my bug.

Essentially tester-client is not reading stuff if the write socket
is blocked. The kernel never does this.

The server is quite within its rights to handle requests one at
a time, i.e. read a request, deal with it in its entirety, and write
the result. That's even in the protocol specification.

I break that, because of buffering, so I should fix it in the tester
client. A simple example of me breaking it would be that I send
a single large read request, which the client starts processing,
which is larger than the socket buffers. Whilst this is happening, I start
a single large write request which is again larger than the socket
buffers. The client is entitled to fully process the read before it
commences on the write, and to do so needs to write it to the socket.
But it can't complete this write, because the socket buffer is full,
as the tester client is busy writing and not reading.

This can't (as a general point) be fixed in the server without saying
the server should have access to an infinite amount of memory. Suppose
the write request overlapped the read? Where would it put it?

--
Alex Bligh