| OLD | NEW |
| (Empty) | |
| 1 /* |
| 2 * Copyright 2011 Google Inc. |
| 3 * |
| 4 * Licensed under the Apache License, Version 2.0 (the "License"); |
| 5 * you may not use this file except in compliance with the License. |
| 6 * You may obtain a copy of the License at |
| 7 * |
| 8 * http://www.apache.org/licenses/LICENSE-2.0 |
| 9 * |
| 10 * Unless required by applicable law or agreed to in writing, software |
| 11 * distributed under the License is distributed on an "AS IS" BASIS, |
| 12 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| 13 * See the License for the specific language governing permissions and |
| 14 * limitations under the License. |
| 15 */ |
| 16 // |
| 17 // Specification of protocol buffers and the client-server protocol that |
| 18 // are used by the clients of the system. |
| 19 // |
| 20 // Note: unless otherwise specified in a comment, all fields in all messages |
| 21 // are required, even though they are listed as optional. |
| 22 |
| 23 syntax = "proto2"; |
| 24 |
| 25 package com.google.protos.ipc.invalidation; |
| 26 |
| 27 option optimize_for = LITE_RUNTIME; |
| 28 |
| 29 |
| 30 |
| 31 option java_outer_classname = "NanoClientProtocol"; |
| 32 option java_package = "com.google.protos.ipc.invalidation"; |
| 33 |
| 34 |
| 35 |
| 36 // Here is a high-level overview of the protocol. The protocol is designed in a |
| 37 // "message-passing" style, i.e., the client (C) or the server (S) can send any |
| 38 // message SPONTANEOUSLY at any time and both sides have to be prepared for any |
| 39 // message from the other side. However, even with this style, there are some |
| 40 // "flows" which are somewhat like requests and replies. |
| 41 |
| 42 // 1. Initialization: When a client starts up, it needs a token to alow it to |
| 43 // perform any other operation with the server. |
| 44 // C -> S: InitializeMessage |
| 45 // S -> C: TokenControlMessage |
| 46 // |
| 47 // 2. Registration: When a client has to register or unregister for a set of |
| 48 // objects, the following flow occurs: |
| 49 // C -> S: RegistrationMessage |
| 50 // S -> C: RegistrationStatusMessage |
| 51 // |
| 52 // 3. Invalidation: The server sends an invalidation and the client sends back |
| 53 // an ack. |
| 54 // S -> C InvalidationMessage |
| 55 // C -> S InvalidationMessage |
| 56 // |
| 57 // 4. Registration sync: Once in a while the server may detect that the client |
| 58 // and server's registration state is out of sync (the server can detect this |
| 59 // since it gets the client's registration summary in the client's message |
| 60 // header). In that case, it asks the client some registration information |
| 61 // and the client sends it to the server. |
| 62 // S -> C: RegistrationSyncRequestMessage |
| 63 // C -> S: RegistrationSyncMessage |
| 64 // |
| 65 // 5. Information messages: The server can occasionally for client-side |
| 66 // information such as statistics, etc. The client responds with the |
| 67 // requested information |
| 68 // S -> C: InfoRequestMessage |
| 69 // C -> S: InfoMessage |
| 70 // |
| 71 // Client protocol messages are typically validated. Validation rules may be |
| 72 // declared in the following locations when making changes to this file: |
| 73 // |
| 74 // 1. TiclMessageValidator2.java: validation logic that is run on the |
| 75 // server. |
| 76 // |
| 77 // 2. ClientProtoWrapperGenerator.java: validation logic that is run |
| 78 // on the client. |
| 79 // ------------------------------------------------------------------------ |
| 80 |
| 81 // A basic message type used for versioning public proto messages and/or |
| 82 // types. The two fields are supposed to be used as follows: |
| 83 // |
| 84 // * The major version number is changed whenever an incompatible protocol |
| 85 // change or type has been made. When a message/object with a particular |
| 86 // major version is received, the receiver needs to either know how to handle |
| 87 // this version or it needs to drop the message |
| 88 // |
| 89 // * The minor version can be changed (say) to document some internal change |
| 90 // for debugging purposes. When a message is received by a receiver, it MUST |
| 91 // ignore the minor version number for making any protocol/type |
| 92 // decisions. I.e., the minor version number is for debugging purposes only. |
| 93 // |
| 94 // Versioning is used in various places - for entities that are part of a |
| 95 // protocol (e.g., message requests), for various client implementations, and |
| 96 // for other data types that change independently of the protocol (e.g., |
| 97 // session tokens). For each versioned entity, we define a specific message |
| 98 // type to encapsulate the version of that entity (e.g., ProtocolVersion, |
| 99 // ClientVersion, etc.). |
| 100 message Version { |
| 101 optional int32 major_version = 1; |
| 102 optional int32 minor_version = 2; |
| 103 } |
| 104 |
| 105 // Message included in all client <-> server messages to indicate the version |
| 106 // of the protocol in use by the sender. |
| 107 message ProtocolVersion { |
| 108 optional Version version = 1; |
| 109 } |
| 110 |
| 111 // Defines a specific version of the client library (for information purposes |
| 112 // only) May not be used to make decisions at the server (use ProtocolVersion |
| 113 // instead). |
| 114 message ClientVersion { |
| 115 |
| 116 // A client-specific version number. |
| 117 optional Version version = 1; |
| 118 |
| 119 // All fields below are for informational/debugging/monitoring purposes only. |
| 120 // No critical code decision is supposed to be made using them. |
| 121 |
| 122 // Optional: information about the client operating system/platform, e.g., |
| 123 // Windows, ChromeOS. |
| 124 optional string platform = 2; |
| 125 |
| 126 // Optional: language used for the library. |
| 127 optional string language = 3; |
| 128 |
| 129 // Optional: extra information about the client (e.g., application name). |
| 130 optional string application_info = 4; |
| 131 } |
| 132 |
| 133 // Message indicating the result of an operation. |
| 134 message StatusP { |
| 135 |
| 136 // Whether operation is successful or not |
| 137 enum Code { |
| 138 SUCCESS = 1; |
| 139 TRANSIENT_FAILURE = 2; |
| 140 PERMANENT_FAILURE = 3; |
| 141 } |
| 142 |
| 143 optional Code code = 1; |
| 144 |
| 145 // Textual description of the status or additional context about any |
| 146 // error. (Optional - Can be set for success also.) |
| 147 optional string description = 2; |
| 148 } |
| 149 |
| 150 // Identifies an object that a client can register for. |
| 151 message ObjectIdP { |
| 152 |
| 153 // The source of the data. |
| 154 optional int32 source = 1; |
| 155 |
| 156 // The id of the object relative to the source. Must be <= 64 bytes. |
| 157 optional bytes name = 2; |
| 158 } |
| 159 |
| 160 // A message containing the part of the client's id that the application |
| 161 // controls. This id is used for squelching invalidations on the server side. |
| 162 // For example, if a client C1 modifies object x and informs the backend about |
| 163 // C1's application client id as part of the invalidation. The backend can then |
| 164 // avoid sending the invalidation unnecessarily to that client. |
| 165 // |
| 166 // If the application wishes to use this squelching feature, it must assign a |
| 167 // globally unique client_name for a given client_type so that the particular |
| 168 // instantation of the application can be identified. |
| 169 message ApplicationClientIdP { |
| 170 // The type of the client. |
| 171 optional int32 client_type = 1; |
| 172 |
| 173 // A client name or unique id assigned by the application. Application should |
| 174 // choose a unique name for different client instances if it wants to squelch |
| 175 // invalidations by name (as discussed above). |
| 176 optional bytes client_name = 2; |
| 177 } |
| 178 |
| 179 // Invalidation for a given object/version. |
| 180 message InvalidationP { |
| 181 // The id of the object being invalidated. |
| 182 optional ObjectIdP object_id = 1; |
| 183 |
| 184 // Whether the invalidation is for a known version of the object as assigned |
| 185 // by an application backend (is_known_version == true) or an unknown system |
| 186 // version synthesized by the invalidation service. (Note that if |
| 187 // is_known_version is false then is_trickle_restart be true or missing |
| 188 // because an unknown version implies that invalidation versions prior to the |
| 189 // current backend version may have been dropped.) |
| 190 optional bool is_known_version = 2; |
| 191 |
| 192 // Version being invalidated (see comment on is_known_version). If the |
| 193 // is_known_version is false, the version corresponds to an internal "system |
| 194 // version" for *that* object. An object's system version has no meaning to |
| 195 // the application other than the fact that these system versions are also |
| 196 // monotonically increasing and the client must ack such an invalidation with |
| 197 // this system version (and an ack for a later system version acknowledges an |
| 198 // invalidation for all earlier system version for *that* object. |
| 199 optional int64 version = 3; |
| 200 |
| 201 // Whether the object's Trickle is restarting at this version. |
| 202 // sets this value to true to inform Trickle API clients that it may |
| 203 // have dropped invalidations prior to "version", or, if is_known_version is |
| 204 // false, prior to the current backend version. This field is logically |
| 205 // required and is always set by current code. The default is true because |
| 206 // old Android invalidation clients strip this field when acking |
| 207 // invalidations due to ProtoLite limitations; true is the correct default |
| 208 // because invalidation clients logically ack all current versions and |
| 209 // because old persisted invalidations are all restarted. |
| 210 optional bool is_trickle_restart = 6 [default = true]; |
| 211 |
| 212 // Optional payload associated with this invalidation. |
| 213 optional bytes payload = 4; |
| 214 |
| 215 // DEPRECATED: bridge arrival time is now maintained by |
| 216 // InvalidationMetadataP in the SourcedInvalidation, InvalidationContents and |
| 217 // ClientInvalidation containers. |
| 218 optional int64 bridge_arrival_time_ms_deprecated = 5 [deprecated=true]; |
| 219 } |
| 220 |
| 221 // Specifies the intention to change a registration on a specific object. To |
| 222 // update registrations, a client sends a message containing repeated |
| 223 // RegistrationP messages. |
| 224 message RegistrationP { |
| 225 enum OpType { |
| 226 REGISTER = 1; |
| 227 UNREGISTER = 2; |
| 228 } |
| 229 |
| 230 // The object for which to (un)register. |
| 231 optional ObjectIdP object_id = 1; |
| 232 |
| 233 // Whether to register or unregister. |
| 234 optional OpType op_type = 2; |
| 235 } |
| 236 |
| 237 // Summary of the registration state associated with a particular client, sent |
| 238 // in the header of client<->server messages. This summary has two different |
| 239 // (but related) meanings depending on where it is used: |
| 240 // |
| 241 // 1) In a client->server message, it describes the DESIRED client state. |
| 242 // 2) In a server->client message, it describes the ACTUAL state at the server |
| 243 // for that client. |
| 244 message RegistrationSummary { |
| 245 // Number of registrations desired (client) or held (server). |
| 246 optional int32 num_registrations = 1; |
| 247 |
| 248 // Top-level digest over the registrations. |
| 249 // |
| 250 // The digest for an object id is computed as following (the digest chosen for |
| 251 // this method is SHA-1): |
| 252 // |
| 253 // digest = new Digest(); |
| 254 // digest.update(Little endian encoding of object source type) |
| 255 // digest.update(object name) |
| 256 // digest.getDigestSummary() |
| 257 // |
| 258 // For a set of objects, digest is computing by sorting lexicographically |
| 259 // based on their digests and then performing the update process given above |
| 260 // (i.e., calling digest.update on each object's digest and then calling |
| 261 // getDigestSummary at the end). |
| 262 optional bytes registration_digest = 2; |
| 263 } |
| 264 |
| 265 // Header included on every client -> server message. |
| 266 message ClientHeader { |
| 267 |
| 268 // Protocol version of this message. |
| 269 optional ProtocolVersion protocol_version = 1; |
| 270 |
| 271 // Token identifying the client. Tokens are issued by the server in response |
| 272 // to client requests (see InitializeMessage, below). In order to perform any |
| 273 // operation other than initialization, the client must supply a token. When |
| 274 // performing initialization, this field must be left unset. |
| 275 optional bytes client_token = 2; |
| 276 |
| 277 // Optional summary of the client's desired registration state. The client is |
| 278 // encouraged to provide this summary in every message once a "steady" state |
| 279 // of registrations/unregistrations has been reached. For example, it may not |
| 280 // want to send this summary during initialization (but after the initial set |
| 281 // has been registered, it should try to send it). |
| 282 optional RegistrationSummary registration_summary = 3; |
| 283 |
| 284 // Timestamp from the client's clock, expressed as ms since 00:00:00 UTC, 1 |
| 285 // January 1970 (i.e., the UNIX epoch) - for debugging/monitoring purposes. |
| 286 optional int64 client_time_ms = 4; |
| 287 |
| 288 // Highest server timestamp observed by the client (the server includes its |
| 289 // time on every message to the client). Note: this time is NOT necessarily |
| 290 // expressed as relative to the UNIX epoch - for debugging/monitoring |
| 291 // purposes. |
| 292 optional int64 max_known_server_time_ms = 5; |
| 293 |
| 294 // Message id to identify the message -for debugging/monitoring purposes. |
| 295 optional string message_id = 6; |
| 296 |
| 297 // Client typecode (as in the InitializeMessage, below). This field may or |
| 298 // may not be set. |
| 299 optional int32 client_type = 7; |
| 300 } |
| 301 |
| 302 // A message from the client to the server. |
| 303 message ClientToServerMessage { |
| 304 // Header. |
| 305 optional ClientHeader header = 1; |
| 306 |
| 307 // Any or all of the follow messages may be present. |
| 308 |
| 309 // Optional initialization message, used to obtain a new token. Note that, if |
| 310 // present, this message is always processed before the messages below, and |
| 311 // those messages will be interpreted relative to the new token assigned here. |
| 312 optional InitializeMessage initialize_message = 2; |
| 313 |
| 314 // Optional request to perform registrations. |
| 315 optional RegistrationMessage registration_message = 3; |
| 316 |
| 317 // Optional data for registration sync. |
| 318 optional RegistrationSyncMessage registration_sync_message = 4; |
| 319 |
| 320 // Optional invalidation acks. |
| 321 optional InvalidationMessage invalidation_ack_message = 5; |
| 322 |
| 323 // Optional information about the client. |
| 324 optional InfoMessage info_message = 6; |
| 325 } |
| 326 |
| 327 // Used to obtain a new token when the client does not have one. |
| 328 message InitializeMessage { |
| 329 |
| 330 // Defines how clients serialize object ids when computing digests for |
| 331 // registrations. |
| 332 enum DigestSerializationType { |
| 333 |
| 334 // The digest for an object id is computed by serializing the object id into |
| 335 // bytes. |
| 336 BYTE_BASED = 1; |
| 337 |
| 338 // The digest for an object id is computed by serializing the object id into |
| 339 // an array of numbers. TODO: Determine and specify this |
| 340 // more precisely. |
| 341 NUMBER_BASED = 2; |
| 342 } |
| 343 |
| 344 // Type of the client. This value is assigned by the backend notification |
| 345 // system (out-of-band) and the client must use the correct value. |
| 346 optional int32 client_type = 1; |
| 347 |
| 348 // Nonce. This value will be echoed as the existing token in the header of |
| 349 // the server message that supplies the new token (the new token itself will |
| 350 // be provided in a TokenControlMessage; see below). |
| 351 optional bytes nonce = 2; |
| 352 |
| 353 // Id of the client as assigned by the application. |
| 354 optional ApplicationClientIdP application_client_id = 3; |
| 355 |
| 356 // Type of registration digest used by this client. |
| 357 optional DigestSerializationType digest_serialization_type = 4; |
| 358 } |
| 359 |
| 360 // Registration operations to perform. |
| 361 message RegistrationMessage { |
| 362 repeated RegistrationP registration = 1; |
| 363 } |
| 364 |
| 365 // Message from the client to the server. |
| 366 message RegistrationSyncMessage { |
| 367 |
| 368 // Objects for which the client is registered. |
| 369 repeated RegistrationSubtree subtree = 1; |
| 370 } |
| 371 |
| 372 // Message sent from the client to the server about registered objects |
| 373 // (typically) in response to a registration sync request. |
| 374 // |
| 375 // The name of the message implies a "tree" for future expansion where the |
| 376 // intention is to not necessarily send the complete set of objects but to |
| 377 // partition the object space into multiple ranges and then exchange Merkle-tree |
| 378 // like data structures to determine which ranges are out-of-sync. |
| 379 message RegistrationSubtree { |
| 380 // Registered objects |
| 381 repeated ObjectIdP registered_object = 1; |
| 382 } |
| 383 |
| 384 // A message from the client to the server with info such as performance |
| 385 // counters, client os info, etc. |
| 386 message InfoMessage { |
| 387 optional ClientVersion client_version = 1; |
| 388 |
| 389 // Config parameters used by the client. |
| 390 // Deprecated and removed - the client_config parameter is what is used now. |
| 391 repeated PropertyRecord config_parameter = 2; |
| 392 |
| 393 // Performance counters from the client. |
| 394 repeated PropertyRecord performance_counter = 3; |
| 395 |
| 396 // If 'true', indicates that the client does not know the server's |
| 397 // registration summary, so the server should respond with it even if the |
| 398 // client's summary matches the server's. |
| 399 optional bool server_registration_summary_requested = 4; |
| 400 |
| 401 // Configuration parameters for this client. |
| 402 optional ClientConfigP client_config = 5; |
| 403 } |
| 404 |
| 405 // Information about a single config/performance counter value in the |
| 406 // InfoMessage. |
| 407 message PropertyRecord { |
| 408 |
| 409 // Name of the performance counter/config parameter. |
| 410 optional string name = 1; |
| 411 |
| 412 // Value of the performance counter/config parameter. |
| 413 optional int32 value = 2; |
| 414 } |
| 415 |
| 416 message ServerHeader { |
| 417 // Protocol version of this message. |
| 418 optional ProtocolVersion protocol_version = 1; |
| 419 |
| 420 // Current token that the server expects the client to have. Clients must |
| 421 // ignore messages where this token field does not match their current token. |
| 422 // During initialization, the client's "token" is the nonce that it generates |
| 423 // and sends in the InitializeMessage. |
| 424 optional bytes client_token = 2; |
| 425 |
| 426 // Summary of registration state held by the server for the client. |
| 427 optional RegistrationSummary registration_summary = 3; |
| 428 |
| 429 // Timestamp from the server's clock. No guarantee on when this time is |
| 430 // relative to. |
| 431 optional int64 server_time_ms = 4; |
| 432 |
| 433 // Message id to identify the message (for debug purposes only). |
| 434 optional string message_id = 5; |
| 435 } |
| 436 |
| 437 // If ServerToClientMessage is modified, you need to change the type |
| 438 // TestServerToClientMessageWithExtraFields in the same way to match. |
| 439 message ServerToClientMessage { |
| 440 optional ServerHeader header = 1; |
| 441 |
| 442 // Message to assign a new client token or invalidate an existing one. Note |
| 443 // that, if present, this message is always processed before the messages |
| 444 // below, and those messages will be interpreted relative to the new token |
| 445 // assigned here. |
| 446 optional TokenControlMessage token_control_message = 2; |
| 447 |
| 448 // Invalidations. |
| 449 optional InvalidationMessage invalidation_message = 3; |
| 450 |
| 451 // Registration operation replies. |
| 452 optional RegistrationStatusMessage registration_status_message = 4; |
| 453 |
| 454 // Request for client registration state. |
| 455 optional RegistrationSyncRequestMessage registration_sync_request_message = 5; |
| 456 |
| 457 // Request to change config from the server. |
| 458 optional ConfigChangeMessage config_change_message = 6; |
| 459 |
| 460 // Request for client information. |
| 461 optional InfoRequestMessage info_request_message = 7; |
| 462 |
| 463 // Asynchronous error information that the server sends to the client. |
| 464 optional ErrorMessage error_message = 8; |
| 465 } |
| 466 |
| 467 // Message used to supply a new client token or invalidate an existing one. |
| 468 message TokenControlMessage { |
| 469 // If status is failure, new_token cannot be set. |
| 470 optional bytes new_token = 1; // If missing, means destroy_token |
| 471 } |
| 472 |
| 473 // Status of a particular registration (could be sent spontaneously by the |
| 474 // server or in response to a registration request). |
| 475 message RegistrationStatus { |
| 476 optional RegistrationP registration = 1; |
| 477 optional StatusP status = 2; |
| 478 } |
| 479 |
| 480 // Registration status of several messages from the server to the client. |
| 481 message RegistrationStatusMessage { |
| 482 repeated RegistrationStatus registration_status = 1; |
| 483 } |
| 484 |
| 485 // Request from the server to get the registration info from the client for |
| 486 // sync purposes. |
| 487 message RegistrationSyncRequestMessage { |
| 488 } |
| 489 |
| 490 // A set of invalidations from the client to the server or vice-versa |
| 491 message InvalidationMessage { |
| 492 repeated InvalidationP invalidation = 1; |
| 493 } |
| 494 |
| 495 // A request from the server to the client for information such as |
| 496 // performance counters, client os, etc |
| 497 message InfoRequestMessage { |
| 498 enum InfoType { |
| 499 GET_PERFORMANCE_COUNTERS = 1; |
| 500 } |
| 501 repeated InfoType info_type = 1; |
| 502 } |
| 503 |
| 504 // A rate limit: a count of events and a window duration in which the events |
| 505 // may occur. |
| 506 message RateLimitP { |
| 507 |
| 508 // The size of the window over which the rate limit applies. |
| 509 optional int32 window_ms = 1; |
| 510 |
| 511 // The number of events allowed within a given window. |
| 512 optional int32 count = 2; |
| 513 } |
| 514 |
| 515 // Configuration parameters for the protocol handler in the Ticl. |
| 516 message ProtocolHandlerConfigP { |
| 517 // Batching delay - certain messages (e.g., registrations, invalidation acks) |
| 518 // are sent to the server after this delay. |
| 519 optional int32 batching_delay_ms = 1 [default = 500]; |
| 520 |
| 521 // Rate limits for sending messages. Only two levels allowed currently. |
| 522 repeated RateLimitP rate_limit = 2; |
| 523 } |
| 524 |
| 525 // Configuration parameters for the Ticl. |
| 526 message ClientConfigP { |
| 527 |
| 528 optional Version version = 1; |
| 529 |
| 530 // The delay after which a network message sent to the server is considered |
| 531 // timed out. |
| 532 optional int32 network_timeout_delay_ms = 2 [default = 60000]; |
| 533 |
| 534 // Retry delay for a persistent write if it fails |
| 535 optional int32 write_retry_delay_ms = 3 [default = 10000]; |
| 536 |
| 537 // Delay for sending heartbeats to the server. |
| 538 optional int32 heartbeat_interval_ms = 4 [default = 1200000]; |
| 539 |
| 540 // Delay after which performance counters are sent to the server. |
| 541 optional int32 perf_counter_delay_ms = 5 [default = 21600000]; // 6 hours. |
| 542 |
| 543 // The maximum exponential backoff factor used for network and persistence |
| 544 /// timeouts. |
| 545 optional int32 max_exponential_backoff_factor = 6 [default = 500]; |
| 546 |
| 547 // Smearing percent for randomizing delays. |
| 548 optional int32 smear_percent = 7 [default = 20]; |
| 549 |
| 550 // Whether the client is transient, that is, does not write its session |
| 551 // token to durable storage. |
| 552 // TODO: need to expose to the clients. |
| 553 optional bool is_transient = 8 [default = false]; |
| 554 |
| 555 // Initial delay for a heartbeat after restarting from persistent state. We |
| 556 // use this so that the application has a chance to respond to the |
| 557 // reissueRegistrations call. |
| 558 optional int32 initial_persistent_heartbeat_delay_ms = 9 [default = 2000]; |
| 559 |
| 560 // Configuration for the protocol client to control batching etc. |
| 561 optional ProtocolHandlerConfigP protocol_handler_config = 10; |
| 562 |
| 563 // Whether the channel supports delivery while the client is offline. If |
| 564 // true, then the servers' use of the channel is such that the |
| 565 // following holds: if any number of messages are sent to the client while |
| 566 // the client is unreachable, then the channel will eventually deliver at |
| 567 // least one message to the client such that, on receiving the message, the |
| 568 // client will send a message to the server. E.g., the channel could deliver |
| 569 // a single invalidation or a single registration sync request. C2DM is |
| 570 // an example of a suitable channel. |
| 571 // |
| 572 // When this is true, the Ticl will record in persistent storage the last |
| 573 // time it sent a message to the server. On persistent restart, it will not |
| 574 // send a message to the server unless the last one was sent more than a |
| 575 // heartbeat-interval ago. This is designed to support efficient Android |
| 576 // clients, which will destroy and recreate the Ticl when transitioning |
| 577 // between foreground and background states. |
| 578 optional bool channel_supports_offline_delivery = 11 [default = false]; |
| 579 |
| 580 // If the client loses network connectivity, it will send a heartbeat after it |
| 581 // comes online, unless it had already sent a message more recently than this |
| 582 // threshold. |
| 583 optional int32 offline_heartbeat_threshold_ms = 12 [default = 60000]; |
| 584 |
| 585 // Whether the client allows suppression. If true (the default), then |
| 586 // both continuous and restarted invalidations result in an invalidate() |
| 587 // upcall, which is appropriate for invalidation clients. If false, |
| 588 // then restarted invalidations result in an invalidateUnknownVersion() |
| 589 // upcall, which provides correct semantics for Trickles clients. |
| 590 optional bool allow_suppression = 13 [default = true]; |
| 591 } |
| 592 |
| 593 // A message asking the client to change its configuration parameters |
| 594 message ConfigChangeMessage { |
| 595 |
| 596 // On receipt of this value, do not send any new message to the server |
| 597 // for the specified delay (this message needs to be accepted without |
| 598 // any token check). A zero value is ignored by the client. So the lowest |
| 599 // value for this field is 1. This concept exists to allow the server |
| 600 // to tell the clients that they should not come back to the server |
| 601 // for some period of time. |
| 602 optional int64 next_message_delay_ms = 1; |
| 603 } |
| 604 |
| 605 // An error message that contains an enum for different types of failures with a |
| 606 // textual description of the failure (as the need arises new error codes will |
| 607 // be added to this message). |
| 608 message ErrorMessage { |
| 609 |
| 610 enum Code { |
| 611 AUTH_FAILURE = 1; // Authorization or authentication failure. |
| 612 UNKNOWN_FAILURE = 10000; // Some failure which is not described above. |
| 613 }; |
| 614 |
| 615 optional Code code = 1; |
| 616 |
| 617 // Textual description of the error |
| 618 optional string description = 2; |
| 619 } |
| OLD | NEW |