4.3. Resolver Operation Options

4.3.1. Minimum Values for Advertisement and Query Intervals

These intervals have the following effective minimal values.

• 10 ms for Initial Phase Advertisements

• 20 ms for Initial Phase Queries

• 30 ms Wildcard Queries

• 100 ms for Sustaining Phase Advertisements and Queries

These effective minimums exist because the internal timer that schedules advertisements and queries fires at the stated interval, i.e., every 10 ms for Initial Phase Advertisements, every 20 ms for Initial Phase Queries, etc. If you set the option's value below the minimum, after the the initial advertisement or query at 0 ms, the resolver schedules the second advertisement or query at the first timer "tick", which is the minimum. Subsequent advertisements or queries can only be issued at the next timer "tick". If you increase this option from the default to a value that is not a multiple of the minimum, the resolver maintains the rate you establish as an average over subsequent "ticks".

As an example, If you set resolver_advertisement_sustain_interval or resolver_query_sustain_interval at 10 ms, the resolver schedules the second advertisement or query after the initial (0 ms) at the first timer "tick", which is 100 ms. Subsequent advertisements or queries can only be issued at the next timer "tick" (every 100 ms). If you increase either option from the default to 1.25 seconds, for example and not a multiple of 100 ms, the resolver maintains the rate you establish as an average over subsequent "ticks". That is, the second advertisement or query goes out at the 1300 ms "tick". The resolver tracks the tardiness of this advertisement (50 ms) and adjusts the next advertisement or query, which goes out at 2500 ms, giving an average of 1250 ms or 1.25 seconds.

4.3.2. disable_extended_topic_resolution_message_options (context)

This is a topic resolution compatibility option that, when set to 1, lets LBM 4.0 (or later) installations work with LBM 3.5.3 / UME 2.2.4 (or earlier) installations. If you do not have early-version installations in the network, leave this option at 0.

4.3.3. resolution_no_source_notification_threshold (receiver)

The threshold for the number of unanswered topic resolution queries before UM delivers a LBM_MSG_NO_SOURCE_NOTIFICATION for the topic. The receiver does not stop querying after the delivery of this notification. A value of 0 indicates no notifications will be sent.

4.3.4. resolution_number_of_sources_query_threshold (receiver)

The threshold for the number of sources a topic must have before topic resolution queries are not sent. A value of zero results in no topic resolution queries being generated. See also Disabling Aspects of Topic Resolution .

4.3.5. resolver_advertisement_maximum_initial_interval (source)

The longest - and last - interval in the initial phase of topic advertisement. A value of 0 disables the initial phase of advertisement. See also Disabling Aspects of Topic Resolution.

4.3.6. resolver_advertisement_minimum_initial_duration (source)

The duration of the initial phase of topic advertisement. A value of 0 guarantees that the initial phase of advertisement never completes.

4.3.7. resolver_advertisement_minimum_initial_interval (source)

Interval between the first topic advertisement sent upon creation of the source and the second advertisement sent by the source. A value of 0 disables the initial phase of advertisement. See also Disabling Aspects of Topic Resolution. This option has an effective minimum of 10 ms. See Minimum Values for Advertisement and Query Intervals.

4.3.8. resolver_advertisement_minimum_sustain_duration (source)

The duration of the sustaining phase of topic advertisement. A value of 0 guarantees that the sustaining phase of advertising never completes.

4.3.9. resolver_advertisement_send_immediate_response (source)

Allows you to disable the normal immediate response to queries and wildcard queries. Sources normally send topic advertisements (TIR) immediately in response to topic queries (TQR) for a local topic or wildcard queries (WC-TQR) with a pattern that matches a local topic. If you configure sources to delay sending advertisements, UM delays advertisements by the limits defined by the advertisement rate limiter options, resolver_*_bps and resolver_*_per_second.

4.3.10. resolver_advertisement_sustain_interval (source)

Interval between sending topic advertisements in the sustaining phase of topic advertisement. A value of 0 disables the sustaining phase of advertisement. See also Disabling Aspects of Topic Resolution. This option has an effective minimum of 100 ms. See Minimum Values for Advertisement and Query Intervals.

4.3.11. resolver_cache (context)

Whether or not to cache topic resolution information. When topic resolution information is not cached, it takes up less memory. However, wildcard receivers will only see topics that have other UM receivers created. And source notification only occurs for topics that have UM receivers created.

4.3.12. resolver_datagram_max_size (context)

The maximum datagram size that can be generated for topic resolution advertisements and queries. The default value is 8192, the minimum is 500 bytes, and the maximum is 65535.

4.3.13. resolver_initial_advertisement_bps (context)

Maximum advertisement rate during the initial phase of topic advertisement. A value of 0 sets no rate limit on advertisements in the initial phase of topic advertisement.

4.3.14. resolver_initial_advertisements_per_second (context)

Maximum number of advertisements sent within a one second period during the initial phase of topic advertisement. A value of 0 sets no rate limit on advertisements in the initial phase of topic advertisement.

4.3.15. resolver_initial_queries_per_second (context)

Maximum number of queries sent within a one second period during the initial phase of topic querying. A value of 0 sets no rate limit on queries in the initial phase of topic querying.

4.3.16. resolver_initial_query_bps (context)

Maximum query rate during the initial phase of topic querying. A value of 0 sets no rate limit on queries in the initial phase of topic querying.

4.3.17. resolver_query_maximum_initial_interval (receiver)

The longest - and last - interval in the initial phase of topic querying. A value of 0 disables the initial phase of querying. See also Disabling Aspects of Topic Resolution.

4.3.18. resolver_query_minimum_initial_duration (receiver)

The duration of the initial phase of topic querying. A value of 0 guarantees that the initial phase of querying never completes.

4.3.19. resolver_query_minimum_initial_interval (receiver)

Interval between the first topic query sent upon creation of the receiver and the second query sent by the receiver. A value of 0 disables the initial phase of querying. See also Disabling Aspects of Topic Resolution. This option has an effective minimum of 20 ms. See Minimum Values for Advertisement and Query Intervals.

4.3.20. resolver_query_minimum_sustain_duration (receiver)

The duration of the sustaining phase of topic querying. A value of 0 guarantees that the sustaining phase of querying never completes.

4.3.21. resolver_query_sustain_interval (receiver)

Interval between sending topic queries in the sustaining phase of topic querying. A value of 0 disables the sustaining phase of querying. See also Disabling Aspects of Topic Resolution. This option has an effective minimum of 100 ms. See Minimum Values for Advertisement and Query Intervals.

4.3.22. resolver_receiver_map_tablesz (context)

The size of the hash table used for storing receiver topic information used for topic resolution. This value should be a prime number.

4.3.23. resolver_send_initial_advertisement (source)

Controls whether or not a source sends an advertisement upon creation. Turning off this advertisement speeds source creation and reduces the number of messages on your network through application initialization.

4.3.24. resolver_source_map_tablesz (context)

The size of the hash table used for storing source topic information used by topic resolution. This value should be a prime number.

4.3.25. resolver_string_hash_function (context)

The hash function to use for hashing topic name strings for source and receiver topics. The application may choose from a list of defined hash functions or it may define its own hash function, as identified by the string value of this option. When setting a hash function, note that:

• If set through a configuration file or a call to lbm_context_attr_str_setopt(), only the string values classic, djb2, sdbm, or murmur2 are valid. (If retrieved by a call to lbm_context_attr_str_getopt(), one of these string values is returned.)

• If set through a call to lbm_context_attr_setopt(), you must pass a pointer to a hash function. Use this method for hash functions other than the four pre-defined functions.

4.3.26. resolver_string_hash_function_ex (context)

This option is similar to the resolver_string_hash_function above, except for the following differences:

• This option can be set via only lbm_context_attr_setopt() (not from a configuration file or lbm_context_attr_str_setopt()). Hence, this also means you cannot use the string options (classic, etc).

• You can pass a string length to the hash function, allowing it to then possibly run faster by operating on multiple-character strings at a time. Note that if -1 is passed in, you must use a strlen to calculate the length.

• The hash function accepts a clientd pointer, which you can set as needed, and which is passed back in each time the function is called.

This option is the better choice when setting your own custom hash function. Note that both the resolver_string_hash_function and resolver_string_hash_function_ex options set the same attributes, hence, if you use both (not recommended) one will override the other.

4.3.27. resolver_sustain_advertisement_bps (context)

Maximum advertisement rate during the sustaining phase of topic advertisement. A value of 0 sets no rate limit on advertisements in the sustaining phase of topic advertisement.

4.3.28. resolver_sustain_advertisements_per_second (context)

Maximum number of advertisements sent within a one second period during the sustaining phase of topic advertisement. A value of 0 sets no rate limit on advertisements in the sustaining phase of topic advertisement.

4.3.29. resolver_sustain_queries_per_second (context)

Maximum number of queries sent within a one second period during the sustaining phase of topic querying. A value of 0 sets no rate limit on queries in the sustaining phase of topic querying.

4.3.30. resolver_sustain_query_bps (context)

Maximum query rate during the sustaining phase of topic querying. A value of 0 sets no rate limit on queries in the sustaining phase of topic querying.

4.3.31. resolver_unicast_activity_timeout (context)

Indicates the maximum time between messages from a unicast resolver daemon before UM declares it inactive and stops sending normal topic resolution traffic via that daemon. UM will still send keepalives to the daemon. A value of 0 will force all resolver daemons to be treated as permanently active.

4.3.32. resolver_unicast_change_interval (context)

Indicates how often UM will change to the next available resolver daemon specified using the. resolver_unicast_daemon configuration option. The actual value used is random, and is selected from the range (1/2*change_interval, 3/2*change_interval). If all resolver daemons have been marked inactive, UM enters a quick-change mode where it uses a random value from the range (1/4*change_interval, 3/4*change_interval) in order to more quickly locate an active daemon.

4.3.33. resolver_unicast_check_interval (context)

Indicates how often a UM checks for resolver activity in order to determine liveness. A value of 0 will disable activity checks. This setting only applies to the unicast resolver.

4.3.34. resolver_unicast_force_alive (context)

Indicates whether sources or receivers in this context should send keepalive messages to a configured Unicast Topic Resolver so they can receive topic resolution traffic.

4.3.35. resolver_unicast_keepalive_interval (context)

Indicates how often keepalive messages should be sent to a resolver daemon. Keepalives are only sent if no other traffic has been sent since the last keepalive interval expired.