• the open/read pattern is poor for startup latency

    this is false. due to using client-assigned identifiers, it is entirely possible (and indeed, recommended) to send an OPEN and READ request in a single TCP packet.

    the random access read model requires the server to buffer the whole of a dynamically generated file, it can’t stream to the client like HTTP

    the protocol is not designed for transfer of dynamically generated files.


    score 1 · canonical

    • Ah I totally missed which end assigns the file handle. I thought that was part of the usual concurrent protocol pattern in which there’s a request ID which is echoed in the corresponding response.

      On re-reading it now it looks like it only allows one open per connection since I can’t see what links READs to OPENs? What happens if there’s more than one OPEN?

      If it doesn’t support uploads or dynamic queries then the title is overselling it just a wee bit.


      score 6 · canonical

      • On re-reading it now it looks like it only allows one open per connection since I can’t see what links READs to OPENs? What happens if there’s more than one OPEN?

        ah, yeah, i guess i was thinking the token field does that, but that’s also supposed to be unique-per request… oops.

        i guess READ needs an open_token field in addition to it’s own token field.

        If it doesn’t support uploads or dynamic queries then the title is overselling it just a wee bit.

        yeah, i definitely didn’t do a good job of communicating the protocol’s limited scope.


        score 1 · canonical