Many resources are needed to download a project. Please understand that we have to compensate our server costs. Thank you in advance. Project price only 1 $
You can buy this project and download/modify it how often you want.
// Generated by the protocol buffer compiler. DO NOT EDIT!
// source: envoy/api/v3alpha/discovery.proto
package io.envoyproxy.envoy.api.v3alpha;
public interface DeltaDiscoveryRequestOrBuilder extends
// @@protoc_insertion_point(interface_extends:envoy.api.v3alpha.DeltaDiscoveryRequest)
com.google.protobuf.MessageOrBuilder {
/**
*
* DeltaDiscoveryRequests allow the client to add or remove individual
* resources to the set of tracked resources in the context of a stream.
* All resource names in the resource_names_subscribe list are added to the
* set of tracked resources and all resource names in the resource_names_unsubscribe
* list are removed from the set of tracked resources.
* *Unlike* state-of-the-world xDS, an empty resource_names_subscribe or
* resource_names_unsubscribe list simply means that no resources are to be
* added or removed to the resource list.
* *Like* state-of-the-world xDS, the server must send updates for all tracked
* resources, but can also send updates for resources the client has not subscribed to.
* NOTE: the server must respond with all resources listed in resource_names_subscribe,
* even if it believes the client has the most recent version of them. The reason:
* the client may have dropped them, but then regained interest before it had a chance
* to send the unsubscribe message. See DeltaSubscriptionStateTest.RemoveThenAdd.
* These two fields can be set in any DeltaDiscoveryRequest, including ACKs
* and initial_resource_versions.
* A list of Resource names to add to the list of tracked resources.
*
* DeltaDiscoveryRequests allow the client to add or remove individual
* resources to the set of tracked resources in the context of a stream.
* All resource names in the resource_names_subscribe list are added to the
* set of tracked resources and all resource names in the resource_names_unsubscribe
* list are removed from the set of tracked resources.
* *Unlike* state-of-the-world xDS, an empty resource_names_subscribe or
* resource_names_unsubscribe list simply means that no resources are to be
* added or removed to the resource list.
* *Like* state-of-the-world xDS, the server must send updates for all tracked
* resources, but can also send updates for resources the client has not subscribed to.
* NOTE: the server must respond with all resources listed in resource_names_subscribe,
* even if it believes the client has the most recent version of them. The reason:
* the client may have dropped them, but then regained interest before it had a chance
* to send the unsubscribe message. See DeltaSubscriptionStateTest.RemoveThenAdd.
* These two fields can be set in any DeltaDiscoveryRequest, including ACKs
* and initial_resource_versions.
* A list of Resource names to add to the list of tracked resources.
*
* DeltaDiscoveryRequests allow the client to add or remove individual
* resources to the set of tracked resources in the context of a stream.
* All resource names in the resource_names_subscribe list are added to the
* set of tracked resources and all resource names in the resource_names_unsubscribe
* list are removed from the set of tracked resources.
* *Unlike* state-of-the-world xDS, an empty resource_names_subscribe or
* resource_names_unsubscribe list simply means that no resources are to be
* added or removed to the resource list.
* *Like* state-of-the-world xDS, the server must send updates for all tracked
* resources, but can also send updates for resources the client has not subscribed to.
* NOTE: the server must respond with all resources listed in resource_names_subscribe,
* even if it believes the client has the most recent version of them. The reason:
* the client may have dropped them, but then regained interest before it had a chance
* to send the unsubscribe message. See DeltaSubscriptionStateTest.RemoveThenAdd.
* These two fields can be set in any DeltaDiscoveryRequest, including ACKs
* and initial_resource_versions.
* A list of Resource names to add to the list of tracked resources.
*
* DeltaDiscoveryRequests allow the client to add or remove individual
* resources to the set of tracked resources in the context of a stream.
* All resource names in the resource_names_subscribe list are added to the
* set of tracked resources and all resource names in the resource_names_unsubscribe
* list are removed from the set of tracked resources.
* *Unlike* state-of-the-world xDS, an empty resource_names_subscribe or
* resource_names_unsubscribe list simply means that no resources are to be
* added or removed to the resource list.
* *Like* state-of-the-world xDS, the server must send updates for all tracked
* resources, but can also send updates for resources the client has not subscribed to.
* NOTE: the server must respond with all resources listed in resource_names_subscribe,
* even if it believes the client has the most recent version of them. The reason:
* the client may have dropped them, but then regained interest before it had a chance
* to send the unsubscribe message. See DeltaSubscriptionStateTest.RemoveThenAdd.
* These two fields can be set in any DeltaDiscoveryRequest, including ACKs
* and initial_resource_versions.
* A list of Resource names to add to the list of tracked resources.
*
* Informs the server of the versions of the resources the xDS client knows of, to enable the
* client to continue the same logical xDS session even in the face of gRPC stream reconnection.
* It will not be populated: [1] in the very first stream of a session, since the client will
* not yet have any resources, [2] in any message after the first in a stream (for a given
* type_url), since the server will already be correctly tracking the client's state.
* (In ADS, the first message *of each type_url* of a reconnected stream populates this map.)
* The map's keys are names of xDS resources known to the xDS client.
* The map's values are opaque resource versions.
*
* Informs the server of the versions of the resources the xDS client knows of, to enable the
* client to continue the same logical xDS session even in the face of gRPC stream reconnection.
* It will not be populated: [1] in the very first stream of a session, since the client will
* not yet have any resources, [2] in any message after the first in a stream (for a given
* type_url), since the server will already be correctly tracking the client's state.
* (In ADS, the first message *of each type_url* of a reconnected stream populates this map.)
* The map's keys are names of xDS resources known to the xDS client.
* The map's values are opaque resource versions.
*
* Informs the server of the versions of the resources the xDS client knows of, to enable the
* client to continue the same logical xDS session even in the face of gRPC stream reconnection.
* It will not be populated: [1] in the very first stream of a session, since the client will
* not yet have any resources, [2] in any message after the first in a stream (for a given
* type_url), since the server will already be correctly tracking the client's state.
* (In ADS, the first message *of each type_url* of a reconnected stream populates this map.)
* The map's keys are names of xDS resources known to the xDS client.
* The map's values are opaque resource versions.
*
* Informs the server of the versions of the resources the xDS client knows of, to enable the
* client to continue the same logical xDS session even in the face of gRPC stream reconnection.
* It will not be populated: [1] in the very first stream of a session, since the client will
* not yet have any resources, [2] in any message after the first in a stream (for a given
* type_url), since the server will already be correctly tracking the client's state.
* (In ADS, the first message *of each type_url* of a reconnected stream populates this map.)
* The map's keys are names of xDS resources known to the xDS client.
* The map's values are opaque resource versions.
*
* Informs the server of the versions of the resources the xDS client knows of, to enable the
* client to continue the same logical xDS session even in the face of gRPC stream reconnection.
* It will not be populated: [1] in the very first stream of a session, since the client will
* not yet have any resources, [2] in any message after the first in a stream (for a given
* type_url), since the server will already be correctly tracking the client's state.
* (In ADS, the first message *of each type_url* of a reconnected stream populates this map.)
* The map's keys are names of xDS resources known to the xDS client.
* The map's values are opaque resource versions.
*
* When the DeltaDiscoveryRequest is a ACK or NACK message in response
* to a previous DeltaDiscoveryResponse, the response_nonce must be the
* nonce in the DeltaDiscoveryResponse.
* Otherwise response_nonce must be omitted.
*
* When the DeltaDiscoveryRequest is a ACK or NACK message in response
* to a previous DeltaDiscoveryResponse, the response_nonce must be the
* nonce in the DeltaDiscoveryResponse.
* Otherwise response_nonce must be omitted.
*
* This is populated when the previous :ref:`DiscoveryResponse <envoy_api_msg_DiscoveryResponse>`
* failed to update configuration. The *message* field in *error_details*
* provides the Envoy internal exception related to the failure.
*
* This is populated when the previous :ref:`DiscoveryResponse <envoy_api_msg_DiscoveryResponse>`
* failed to update configuration. The *message* field in *error_details*
* provides the Envoy internal exception related to the failure.
*
* This is populated when the previous :ref:`DiscoveryResponse <envoy_api_msg_DiscoveryResponse>`
* failed to update configuration. The *message* field in *error_details*
* provides the Envoy internal exception related to the failure.
*