deephaven
Clients should report a gRPC user-agent when connecting, servers should log it
When a client connects, the server should log the client's version number. (This will be very helpful for debugging, especially in environments with multiple clients who may not have pulled the most up-to-date client package.)
From https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md#user-agents
While the protocol does not require a user-agent to function it is recommended that clients provide a structured user-agent string that provides a basic description of the calling library, version & platform to facilitate issue diagnosis in heterogeneous environments. The following structure is recommended to library developers
User-Agent → "grpc-" Language ?("-" Variant) "/" Version ?( " (" *(AdditionalProperty ";") ")" )E.g.
grpc-java/1.2.3 grpc-ruby/1.2.3 grpc-ruby-jruby/1.3.4 grpc-java-android/0.9.1 (gingerbread/1.2.4; nexus5; tmobile)
Each Deephaven client implementation should follow this, probably specifying their grpc version and DH version, and potentially related dependencies (python/c++ should probably include the flight version).
Then, the server should capture this value, at least for error messages logged on the server, and potentially store it in the session (assuming that session tokens are not reused across multiple clients).
Note that the Java client already has wiring to enable it to define a user agent, but at this time only io.deephaven.client.examples.ConnectOptions actually is capable of setting it. The Java FlightClient does not set it either.
Is "Version" here meant to represent the grpc version, or the Deephaven version? We should be internally consistent among our different languages.
I'm assuming something like grpc-java/<grpc-version> (deephaven/<deephaven-version>) would be what we want for the java client?
I'm assuming something like
grpc-java/<grpc-version> (deephaven/<deephaven-version>)would be what we want for the java client?
Yes exactly - the JS client wouldn't list a grpc version (since it doesn't use a grpc client at all), and other clients that leverage arrow flight more directly should also be sure to list that version as well.
Two subtasks that I'll edit in (along with a point per client) after any further discussion: server needs to make some use of these strings, and the grpc-web filter needs to read from x-user-agent instead (see "User Agent" at https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-WEB.md#protocol-differences-vs-grpc-over-http2).
From the perspective of "worker to worker", it may also be good to have a property describing how the server was packaged, ie "native", "py-embedded-server", "dnd", etc.
I had the Deephaven version in mind, but I certainly wouldn't object to more versions (e.g. gRPC version, Barrage version, and anything else that could be useful).
@rbasralian and while we could add a tool that just collects/shares the DH version, it seemed like a better bet to piggyback on the grpc version reporting feature, since we may not want to rely on adding more functionality to existing grpc/flight/etc clients - but they should support this, and in some cases might even make it possible to very lightly extend them to note the versions of any other pieces we add on top.
Need @kosak to weigh in on what may be required to implement this in the R client, as it's backended by the C++ client, like ticking Python. R may or may not be blocked on C++.
There may be special considerations we want to take for the javascript user-agent (if changing the user-agent is even possible from the context of the browser?); it seems like keeping the default browser user-agent and mixing in JS client details would be ideal.
Right now, the JS gRPC from browser sets a user-agent that looks something like:
Mozilla/5.0 (X11; Linux x86_64; rv:129.0) Gecko/20100101 Firefox/129.0