On Tue, Mar 29, 2016 at 11:45:45AM -0600, Eric Blake wrote: > On 03/29/2016 11:34 AM, Alex Bligh wrote: > > I would agree. I think if it supports the structured reply semantics, > > it should also support 'DF'. So if you know the server supports > > structured replies, you know you can set DF on them without any > > further requirements. > > Supporting DF merely transfers the burden of collection between server > and client. I suspect that there are cases where the server does NOT > want to support DF (because it would require the server to allocate > memory to collect the data before sending a single structured read > reply),
There are other ways to handle that; e.g., the server could have a "request too large for non-fragmented read" error message. The spec should give a minimum size that the server MUST support (which should be reasonably large), and should state that a server MAY reply to any request with DF set for a block larger than that minimum, with that error. Otherwise the client could conceivably send out heaps of requests for (UINT32_MAX - 8) bytes with DF set and basically DoS the server. > just as you have stated that there are cases where the client > has an additional burden if DF is not supported. So for v2, I'm going > to explicitly document a DF export flag, and recommend (but not require) > that the server support it. I'd prefer not to see that. -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12