Eric, >>> However, for ease of implementation, a >>> + server MAY close the connection rather than entering transmission >>> + phase if, at the end of option haggling, the client has negotiated >>> + another command that requires a structured reply but did not also >>> + negotiate Structured Reads. >> >> That's pretty yucky given a reconnect will achieve the same result >> and you'll end up in an infinite retry loop. >> >> Wouldn't a better route be simply to say that implementing certain >> commands (server or client sides) requires support of structured >> replies? > > I think we're in agreement that the only command that (for back-compat > reasons) can ever send data on a simple reply is CMD_READ. Therefore, > if you negotiate any other command that can send data, that command will > use a structured reply; the mere fact that you negotiated the command > means that both client and server know about structured replies. > > I guess what I was trying to get at is that if you are using any > structured replies, then it is a disservice to wire-sniffers if you did > not also enable structured replies for CMD_READ. Agree > Technically, it would > be feasible to use simple replies for reads while using structured > replies for the other negotiated commands, Agree > but practically, a client > that does that seems undesirable, which is why I said that a server > could disconnect rather than talking to such a client. I would prefer to make that a protocol breach, i.e. the client MUST NOT do that. > So taking your sentence at face value, yes there is another solution > possible: require that any NBD_OPT_* haggling used to negotiate the use > of any other command with a structured reply MUST fail if the client has > not first negotiated NBD_OPT_STRUCTURED_READ, but leaves the connection > open so the client can continue option haggling. That way, the only way > to end option haggling with the new command enabled is to also enable > structured reads. The burden is then on the client to haggle in the > correct order, and on the server to track haggling state when deciding > how to answer the option requests for the new commands. I think I'm saying something simpler (unless I'm missing something) which is: The client MUST NOT propose NBD_OPT_FOO unless it has previously proposed and the server accepted NBD_OPT_BAR. In this case FOO is e.g. the thing to find holes, BAR is NBD_OPT_STRUCTURED_READ. So it's not a question of leaving the connection open or closing it, it's simply that the client can't propose X unless it's already negotiated Y. If it does, all bets are off, so of course it can close the connection. But this makes it explicit that the client if proposing X should first have successfully negotiated Y. > I'm a bit reluctant to put ordering requirements on option haggling > (that option A must be turned on before option B), but then again, the > SELECT extension requires NBD_OPT_SELECT to be haggled prior to > NBD_OPT_GO, so there's precedent. Resisting such a change would resist the possibility in the future that option X requires option Y. Even if you can get around that this time, I'll bet my bottom dollar it will come up again. > I also am thinking of proposing an > extension for option haggling to communicate minimum/preferred > alignments and maximum don't-fragment sizing, and that option would have > to be enabled before OPT_LIST/OPT_SELECT/OPT_EXPORT_NAME (because it > would change the NBD_REP_SERVER layout in response to those option > requests), which would be another case where option A affects the > behavior of option B. ... and as if by magic! Yeah I was going to suggest a similar option, including a blocksize alignment, a maximum size for a read/write, and a maximum DF size. I'm busy writing an 'example' nbd server in golang and this is the first thing I ran into. The purpose of this BTW is to serve as an example implementation for structured replies. >> These multiple error chunks are neat. However, I suspect lazy implementors >> may just send an error without an offset. > > Any ideas are appreciated on how to word it to suggest that servers > SHOULD try to give full details; but I think we want the fallback to the > no-offset case because some situations will not have an offset. Indeed. Perhaps we can promise them Oreos. > I was thinking that it's easier on the client if the final chunk always > serves as a reliable indicator of success (OFFSET_DATA, OFFSET_HOLE, > NONE) or error (ERROR, ERROR_OFFSET). But if you think that always > allowing a concluding NONE, even on an errored reply due to an earlier > chunk reporting the error, is reasonable, I can relax things along those > lines. Or maybe we can state that the concluding chunk on an errored > reply may be ERROR_OFFSET with 'error' and 'offset' fields set to 0, > rather than forcing the server to replay one of the earlier offsets. I think I'd prefer just that the last chunk has the relevant bit set, and comes before (or is) the error chunk(s). That's lots easier for the server and no more difficult for the client. >>> + the client's length request is larger than 65,536 bytes (or if a >>> + later extension adds a way to negotiate a larger maximum fragment >>> + size), the server MAY reject the command with `EOVERFLOW`. The >>> + `EOVERFLOW` error MUST NOT be used if the `NBD_CMD_FLAG_DF` flag >>> + was not set, or if the requested length is no larger than 65,536. > > I'm also wondering if the wording should be switched along the lines of: > > If the flag is set and the server deems the request to be too large, the > server MAY reject the command with `EOVERFLOW`; however, the server MUST > NOT reject a request that is no larger than 65,536 bytes in this manner. That's clearer. -- Alex Bligh
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail