I'm a little wary of sending the string "Request-Id" with every RPC message. Maybe it's not a big deal, though. How many bytes does it take to send and receive a null?
Thinking out loud, the handshake could negotiate not just the schema for the protocol, but also the schema for the RPC metadata. So there could still be arbitrary data sent in every RPC, but it just so happens that it's typed via an explicit record schema. It would save on sending string keys, but it's a bit meta and more complicated. > > I propose that, in Avro, to permit simple implementations, multiplexing > is optional for TCP socket based clients and servers (including those > with SASL or TLS layered on top). The rule would be that: if a client > sets "Call-Id" in a request's metadata to some value, then a server is > required to set "Call-Id" in the corresponding response's metadata to > the same value. > Is the call-id value arbitrary bytes? We wouldn't break compatibility with what's currently published if the server was allowed to not set call-id if it was responding to things in order. > With this convention, the request and response payload can be just the > framed call data as currently in the spec. The only addition we might > make to fully-define the wire format is to specify a magic number that's > transmitted on connection open. I'm +1 magic number. Some transports might also imply additional per-connection magic. > This would (a) permit a server to > automatically distinguish RPC requests from, e.g., HTTP/HTML requests, > so that a single port can be used to service both, and (b) future-proof > the wire format, since we can use the magic number as a version. > > Hopefully future changes to the wire format can mostly be handled by > adding data to the handshake metadata, but, should that prove > insufficient, the magic number could be incremented. Arguably, in > retrospect, the handshake should be just metadata, with the other > current fields moved to the metadata. The handshake would get slightly > bigger and slower to process, since, e.g., "Client-Hash" and > "Server-Hash" would sent as strings with each request, but it might be > simpler to evolve. > One thing that confused me in this discussion as that handshaking actually happens with every request. (I initially had remembered the older system where handshaking is per-connection instead.) I'm again worried about the costs of using string keys. Maybe that's silly. > On a related note, would it be useful to standardize on a naming > convention for RPC service addresses? For example, a TCP-based, > SASL-authenticated server running on host:port might be > tcp-sasl://u...@host:port/, an http-based server might be named with > http://host:port/, etc. Applications could use this to name servers. > The specification would define a small set of these. > Yes, this would be useful. We should be able to serialize the type of transport and the relevant connection information in a String (and a URI is a reasonable form thereof) so that folks can configure an AVRO connection with a URI. Say there's a server that provides some service. We should be able to configure it to point it at "http+avro://host:port" or "tcp-sasl://host:port" or whatever. Implementations will then provide some form of factory method for creating Transceivers, so idiomatic code snippet would be: XRequestor requestor = new XRequestor(protocol, TransceiverFactory.create("http://....";)); -- Philip
