Re: [Nbd] another?

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

Wouter,

> > 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,
>
> You mean to say that the server starts processing, right?

Yes, sorry.

> > 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.
>
> Right.
>
> > 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?
>
> I thought we'd said that overlapping read or write requests are bad, and
> the client should not do that (because the result will be
> unpredictable), unless there's a FLUSH inbetween.

That was probably a bad example. Overlapping requests are 'supported'
only in the sense that the outcome is undefined (assuming we stick
with linux block layer semantics).

> But yeah, the server should be able to eventually say "hold yer horses,
> there's some stuff here that I want you to handle first". I think the
> only reasonable way to do that is to have the client handle EAGAIN (or
> NBD_ERR_AGAIN, as the case may be) in a reasonable manner.

If I ran a proper select loop, I wouldn't see the problem. I'd
see FD_ISSET returning 1 for both the read and the write FDs,
then when the write FD started to block, I'd see a 0 on there
and a 1 on the read FD (as opposed to sitting in a tight
loop trying to write), I'd then read from the read FD, which
would cause the server to send me the data, until it got back
to its own select loop, whereupon it would read data from the
client, and the client could start writing again.

--
Alex Bligh