Get desktop application:
View/edit binary Protocol Buffers messages
An authentication type. This is modeled as a oneof in case any of these authentication types, or any authentication types in the future, need to add extra type-specific parameters during negotiation.
Used in:
The server and client mutually authenticate via SASL.
The server authenticates the client via a signed token, and the client authenticates the server by verifying its certificate has been signed by a trusted CA. Token authentication requires the connection to be TLS encrypted.
The server and client mutually authenticate by certificate. Certificate authentication requires the connection to be TLS encrypted.
Used in:
(message has no fields)
Used in:
(message has no fields)
Used in:
(message has no fields)
The connection context is sent as part of the connection establishment. It establishes the context for ALL RPC calls within the connection. This is sent on connection setup after the connection preamble is sent and SASL has been negotiated. No response is sent from the server to the client.
UserInfo beyond what is determined as part of security handshake at connection time (kerberos, tokens etc). DEPRECATED: No longer used in Kudu 1.1 and later. The 'real_user' should be taken from the SASL negotiation. Impersonation (effective user) was never supported, so we'll have to add that back at some point later.
If the server sends a nonce to the client during the SASL_SUCCESS negotiation step, the client is required to encode it with SASL integrity protection and return it in this field. The nonce protects the server against a Kerberos replay attack.
Request and response for dumping previously sampled RPC calls.
(message has no fields)
Sent as response when is_error == true.
TODO: Make code required?
Specific error identifier.
If the request is failed due to an unsupported feature flag, the particular flag(s) that were not supported will be sent back to the client.
These codes have all been inherited from Hadoop's RPC mechanism.
Used in:
Non-fatal RPC errors. Connection should be left open for future RPC calls. ------------------------------------------------------------ The application generated an error status. See the message field for more details.
The specified method was not valid.
The specified service was not valid.
The server is overloaded - the client should try again shortly.
The request parameter was not parseable, was missing required fields, or the server does not support the required feature flags.
The server might have previously received this request but its response is no longer cached. It's unknown whether the request was executed or not.
The server is not able to complete the connection or request at this time. The client may try again later.
The authorization token is invalid or expired. Unlike FATAL_INVALID_AUTHENTICATION_TOKEN, receipt of this code does not mean that a reconnection attempt should be made; just that the client should obtain a new authz token.
FATAL_* errors indicate that the client should shut down the connection. ------------------------------------------------------------ The RPC server is already shutting down.
Fields of RpcHeader are invalid.
Could not deserialize RPC request.
IPC Layer version mismatch.
Auth failed.
The authentication token is invalid or expired. The connection negotiation failed, and the client should obtain a new authn token and try to reconnect.
Message type passed back & forth for the SASL negotiation.
When the client sends its NEGOTIATE step message, it sends its set of supported RPC system features. In the response to this message, the server sends back its own. This allows the two peers to agree on whether newer extensions of the RPC system may be used on this connection. We use a list of features rather than a simple version number to make it easier for the Java and C++ clients to implement features in different orders while still maintaining compatibility, as well as to simplify backporting of features out-of-order.
The current negotiation step.
The SASL token, containing either the challenge during the SASL_CHALLENGE step, or the response during the SASL_RESPONSE step.
During the TLS_HANDSHAKE step, contains the TLS handshake message.
The tls-server-end-point channel bindings as specified in RFC 5929. Sent from the server to the client during the SASL_SUCCESS step when the Kerberos (GSSAPI) SASL mechanism is used with TLS, in order to bind the Kerberos authenticated channel to the TLS channel. The value is integrity protected through SASL. The client is responsible for validating that the value matches the expected value.
A random nonce sent from the server to the client during the SASL_SUCCESS step when the Kerberos (GSSAPI) SASL mechanism is used with TLS. The nonce must be sent back to the server, wrapped in SASL integrity protection, as part of the connection context.
During the NEGOTIATE step, contains the supported SASL mechanisms. During the SASL_INITIATE step, contains the single chosen SASL mechanism.
During the client to server NEGOTIATE step, contains the supported authentication types. During the server to client NEGOTIATE step, contains the chosen authentication type.
During the TOKEN_EXCHANGE step, contains the client's signed authentication token.
Used in:
Used in:
The SASL mechanism, i.e. 'PLAIN' or 'GSSAPI'.
Used in:
Service name for the RPC layer. The client created a proxy with this service name. Example: kudu.rpc_test.CalculatorService
Name of the RPC method.
The header for the RPC request frame.
Used in:
,A sequence number that uniquely identifies a call to a single remote server. This number is sent back in the Response and allows to match it to the original Request. Hadoop specifies a uint32 and casts it to a signed int. That is counterintuitive, so we use an int32 instead. Allowed values (inherited from Hadoop): 0 through INT32_MAX: Regular RPC call IDs. -2: Invalid call ID. -3: Connection context call ID. -33: SASL negotiation call ID. NOTE: these calls must be increasing but may have gaps.
RPC method being invoked. Not used for "connection setup" calls.
Propagate the timeout as specified by the user. Note that, since there is some transit time between the client and server, if you wait exactly this amount of time and then respond, you are likely to cause a timeout on the client.
Feature flags that the service must support in order to properly interpret this request. The client can pass any set of flags, and if the server doesn't support any of them, then it will fail the request. NOTE: these are for evolving features at the level of the application, not the RPC framework. Hence, we have to use a generic int type rather than a particular enum. NOTE: the server will only interpret this field if it supports the APPLICATION_FEATURE_FLAGS flag.
The unique id of this request, if it's retriable and if the results are to be tracked. The request id is unique per logical request, i.e. retries of the same RPC must have the same request id. Note that this is different from 'call_id' in that a call_id is unique to a server while a request_id is unique to a logical request (i.e. the request_id remains the same when a request is retried on a different server). Optional for requests that are naturally idempotent or to maintain compatibility with older clients for requests that are not.
Byte offsets for side cars in the main body of the request message. These offsets are counted AFTER the message header, i.e., offset 0 is the first byte after the bytes for this protobuf.
The Id of a retriable RPC, whose results should be tracked on the server (see result_tracker.h). This also includes some information that is useful for execution/garbage collection.
Used in:
The (globally unique) id of the client performing this RPC.
The (per-client unique) sequence number of this RPC.
The sequence number of the first RPC that has not been marked as completed by the client. Unset if there isn't an incomplete RPC.
The number of times this RPC has been tried. Set to 1 in the first attempt.
If this is set, then this is an error response and the response message will be of type ErrorStatusPB instead of the expected response type.
Byte offsets for side cars in the main body of the response message. These offsets are counted AFTER the message header, i.e., offset 0 is the first byte after the bytes for this protobuf.
Used in:
Used in:
States for OutboundCall
Debugging information about a currently-open RPC connection.
Used in:
TODO: swap out for separate fields
Information on the actual TCP connection as reported by the kernel.
Transport-specific details.
Used in:
Connection is still being negotiated.
Connection is active.
Features supported by the RPC system itself. Note that this should be used to evolve the RPC _system_, not the semantics or compatibility of individual calls. For example, if we were to add a feature like call or response wire compression in the future, we could add a flag here to indicate that the client or server supports that feature. Optional features which may safely be ignored by the receiver do not need a feature flag, instead the optional field feature of ProtoBuf may be utilized.
Used in:
The RPC system is required to support application feature flags in the request and response headers.
The RPC system supports TLS protected connections. If both sides support this flag, the connection will automatically be wrapped in a TLS protected channel following a TLS handshake.
If both sides advertise TLS_AUTHENTICATION_ONLY, this means that they agree that, after handshaking TLS, they will *not* wrap the connection in a TLS-protected channel. Instead, they will use TLS only for its handshake-based authentication. This is currently used for loopback connections only, so that compute frameworks which schedule for locality don't pay encryption overhead.
A set of samples for a particular RPC method.
Used in:
A single sampled RPC call.
Used in:
The original request header.
The stringified request trace.
The number of millis that this call took to complete.
The metrics from the sampled trace.
The SocketStatsPB message is used to report on socket-level information for RPC-related TCP connections (Linux-only). Essentially, the message contains some metrics and counters from Linux-specific 'tcp_info' structure defined in /usr/include/linux/tcp.h. For more information on the TCP on Linux, see http://man7.org/linux/man-pages/man7/tcp.7.html
Used in:
Calculated sender throughput.
A particular TraceMetric key/value pair from a sampled RPC.
Used in:
A '.'-separated path through the parent-child trace hierarchy.
Transport-related information for an RPC connection.
Used in:
TCP-specific details.
Used in:
Maximum segment size for the packets: this directly maps into the TCP_MAXSEG socket option.
TLS-specific details. NOTE: TLS/SSL doesn't map nicely into a single layer of the TCP/IP or the OSI model, but intuitively that's something related to the transport.
Used in:
The name of the TLS protocol negotiated to protect the connection (e.g. TLSv1.3).
Description of the TLS cipher suite used.
User Information proto. Included in ConnectionContextPB on connection setup.
Used in:
,