UDP Polling Interval

In BESAdmin > Masthead Management, does anyone know if these drop-down values are cast in stone or how would a person choose 3 hours if they wanted 3 hours?

Seems incredibly inflexible to me.

What do others have this set to?

That relates to the gathering interval, not to a UDP polling interval. Also, those settings are global. I would generally recommend setting it to half a day or day.

There is a client setting for command polling that you can set on individual clients. I set it to 3 hours on all clients and 1 hour on clients that do not get UDP.

UDP messages are sent out immediately, not on that hourly or daily interval, but not all clients can get them, so command polling fills that gap, as does the newer persistent connection option.

Command polling is one of many client settings I adjust for optimal client performance: bigfix-content/fixlet/clientsettings/Recommended Client Settings - Initial Provisioning Speed up - Long term settings.bes at main · jgstew/bigfix-content · GitHub

Command polling is lighter than a full site gather, as it will only check sites that have changes, rather than all sites.

That is not the case, this setting controls how often clients gather sites from the root server, including internal sites which can change quite often as new actions are created.

@jgstew Thanks for the correction :slight_smile:

Gathering Interval:

This option determines how long the clients wait without hearing from the server before they check whether new content is available. In general, whenever the server gathers new content, it attempts to notify the clients that the new content is available through a UDP connection, circumventing this delay. However, in situations where UDP is blocked by firewalls or where network address translation (NAT) remaps the IP address of the client from the servers perspective, a smaller interval becomes necessary to get a timely response from the clients. Higher gathering rates only slightly affect the performance of the server, because only the differences are gathered; a client does not gather information that it already has.

My concern is how long does the relay wait to switch to TCP from UDP if UDP is blocked or not allowed?

setting "_BESClient_Comm_CommandPollEnable"="1" on "{parameter "action issue date" of action}" for client
setting "_BESClient_Comm_CommandPollIntervalSeconds"="3600" on "{parameter "action issue date" of action}" for client

Is that controlled by the settings above (from your link to your xml)?

What are the defaults if not set?

3600 seconds is 1h. Did you say you use 3h?

I also see your xml is from 7y ago. Do you think some of those settings are all still valid?

It doesn’t. As per my understand Relay to client is always UDP. UDP is only the notification “I have work”. If the client is reachable by UDP, it gets the data and proceeds. If UDP is blocked, the client won’t be notified, so you use Command Polling, where the client checks the relay over TCP at a set interval to discover new work.

There is no default setting for command polling, by default it’s not enabled.

Recommendation is don’t set it too aggressively or clients will poll while they’re already busy. Choose an interval that fits your needs. We use 20 minutes to satisfy tighter status-update expectations.

1 Like

Has anyone ever done a network load analysis to see if a more aggressive setting resulted in phone calls from network support asking why Bigfix client is so chatty?