geode-docs/managing/monitor_tune/udp_communication.html.md.erb - geode - Git at Google

 ---
 title:  UDP Communication
 ---

 <!--
 Licensed to the Apache Software Foundation (ASF) under one or more
 contributor license agreements.  See the NOTICE file distributed with
 this work for additional information regarding copyright ownership.
 The ASF licenses this file to You under the Apache License, Version 2.0
 (the "License"); you may not use this file except in compliance with
 the License.  You may obtain a copy of the License at

      http://www.apache.org/licenses/LICENSE-2.0

 Unless required by applicable law or agreed to in writing, software
 distributed under the License is distributed on an "AS IS" BASIS,
 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 See the License for the specific language governing permissions and
 limitations under the License.
 -->

 You can make configuration adjustments to improve multicast and unicast UDP performance of peer-to-peer communication.

 You can tune your <%=vars.product_name%> UDP messaging to maximize throughput. There are two main tuning goals: to use the largest reasonable datagram packet sizes and to reduce retransmission rates. These actions reduce messaging overhead and overall traffic on your network while still getting your data where it needs to go. <%=vars.product_name%> also provides statistics to help you decide when to change your UDP messaging settings.

 Before you begin, you should understand <%=vars.product_name%> [Basic Configuration and Programming](../../basic_config/book_intro.html). See also the general communication tuning and multicast-specific tuning covered in [Socket Communication](socket_communication.html) and [Multicast Communication](multicast_communication.html#multicast).

 ## <a id="udp_comm__section_4089ACC33AF34FA888BAE3CA3602A730" class="no-quick-link"></a>UDP Datagram Size

 You can change the UDP datagram size with the <%=vars.product_name%> property `udp-fragment-size`. This is the maximum packet size for transmission over UDP unicast or multicast sockets. When possible, smaller messages are combined into batches up to the size of this setting.

 Most operating systems set a maximum transmission size of 64k for UDP datagrams, so this setting should be kept under 60k to allow for communication headers. Setting the fragment size too high can result in extra network traffic if your network is subject to packet loss, as more data must be resent for each retransmission. If many UDP retransmissions appear in DistributionStats, you maybe achieve better throughput by lowering the fragment size.

 ## <a id="udp_comm__section_B9882A4EBA004599B2207B9CB1D3ADC9" class="no-quick-link"></a>UDP Flow Control

 UDP protocols typically have a flow-control protocol built into them to keep processes from being
 overrun by incoming no-ack messages. The <%=vars.product_name%> UDP flow-control protocol is a credit based system in
 which the sender has a maximum number of bytes it can send before getting its byte credit count
 replenished, or recharged, by its receivers. While its byte credits are too low, the sender
 waits. The receivers do their best to anticipate the sender’s recharge requirements and provide
 recharges before they are needed. If the sender's credits run too low, it explicitly requests a
 recharge from its receivers.

 This flow-control protocol, which is used for all multicast and unicast no-ack messaging, is
 configured using a three-part <%=vars.product_name%> property `mcast-flow-control`. This property is composed of:

 -   `byteAllowance`—Determines how many bytes (also referred to as credits) can be sent before receiving a recharge from the receiving processes.
 -   `rechargeThreshold`—Sets a lower limit on the ratio of the sender’s remaining credit to its `byteAllowance`. When the ratio goes below this limit, the receiver automatically sends a recharge. This reduces recharge request messaging from the sender and helps keep the sender from blocking while waiting for recharges.
 -   `rechargeBlockMs`—Tells the sender how long to wait while needing a recharge before explicitly requesting one.

 In a well-tuned system, where consumers of cache events are keeping up with producers, the `byteAllowance` can be set high to limit flow-of-control messaging and pauses. JVM bloat or frequent message retransmissions are an indication that cache events from producers are overrunning consumers.

 ## <a id="udp_comm__section_FB1F54A41D2643A29DB416D309ED4C56" class="no-quick-link"></a>UDP Retransmission Statistics

 <%=vars.product_name%> stores retransmission statistics for its senders and receivers. You can use these statistics to help determine whether your flow control and fragment size settings are appropriate for your system.

 The retransmission rates are stored in the DistributionStats `ucastRetransmits` and
 `mcastRetransmits`. For multicast, there is also a receiver-side statistic `mcastRetransmitRequests`
 that can be used to see which processes aren't keeping up and are requesting retransmissions. There
 is no comparable way to tell which receivers are having trouble receiving unicast UDP messages.
	---
	title: UDP Communication
	---

	<!--
	Licensed to the Apache Software Foundation (ASF) under one or more
	contributor license agreements. See the NOTICE file distributed with
	this work for additional information regarding copyright ownership.
	The ASF licenses this file to You under the Apache License, Version 2.0
	(the "License"); you may not use this file except in compliance with
	the License. You may obtain a copy of the License at

	http://www.apache.org/licenses/LICENSE-2.0

	Unless required by applicable law or agreed to in writing, software
	distributed under the License is distributed on an "AS IS" BASIS,
	WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
	See the License for the specific language governing permissions and
	limitations under the License.
	-->

	You can make configuration adjustments to improve multicast and unicast UDP performance of peer-to-peer communication.

	You can tune your <%=vars.product_name%> UDP messaging to maximize throughput. There are two main tuning goals: to use the largest reasonable datagram packet sizes and to reduce retransmission rates. These actions reduce messaging overhead and overall traffic on your network while still getting your data where it needs to go. <%=vars.product_name%> also provides statistics to help you decide when to change your UDP messaging settings.

	Before you begin, you should understand <%=vars.product_name%> [Basic Configuration and Programming](../../basic_config/book_intro.html). See also the general communication tuning and multicast-specific tuning covered in [Socket Communication](socket_communication.html) and [Multicast Communication](multicast_communication.html#multicast).

	## <a id="udp_comm__section_4089ACC33AF34FA888BAE3CA3602A730" class="no-quick-link"></a>UDP Datagram Size

	You can change the UDP datagram size with the <%=vars.product_name%> property `udp-fragment-size`. This is the maximum packet size for transmission over UDP unicast or multicast sockets. When possible, smaller messages are combined into batches up to the size of this setting.

	Most operating systems set a maximum transmission size of 64k for UDP datagrams, so this setting should be kept under 60k to allow for communication headers. Setting the fragment size too high can result in extra network traffic if your network is subject to packet loss, as more data must be resent for each retransmission. If many UDP retransmissions appear in DistributionStats, you maybe achieve better throughput by lowering the fragment size.

	## <a id="udp_comm__section_B9882A4EBA004599B2207B9CB1D3ADC9" class="no-quick-link"></a>UDP Flow Control

	UDP protocols typically have a flow-control protocol built into them to keep processes from being
	overrun by incoming no-ack messages. The <%=vars.product_name%> UDP flow-control protocol is a credit based system in
	which the sender has a maximum number of bytes it can send before getting its byte credit count
	replenished, or recharged, by its receivers. While its byte credits are too low, the sender
	waits. The receivers do their best to anticipate the sender’s recharge requirements and provide
	recharges before they are needed. If the sender's credits run too low, it explicitly requests a
	recharge from its receivers.

	This flow-control protocol, which is used for all multicast and unicast no-ack messaging, is
	configured using a three-part <%=vars.product_name%> property `mcast-flow-control`. This property is composed of:

	- `byteAllowance`—Determines how many bytes (also referred to as credits) can be sent before receiving a recharge from the receiving processes.
	- `rechargeThreshold`—Sets a lower limit on the ratio of the sender’s remaining credit to its `byteAllowance`. When the ratio goes below this limit, the receiver automatically sends a recharge. This reduces recharge request messaging from the sender and helps keep the sender from blocking while waiting for recharges.
	- `rechargeBlockMs`—Tells the sender how long to wait while needing a recharge before explicitly requesting one.

	In a well-tuned system, where consumers of cache events are keeping up with producers, the `byteAllowance` can be set high to limit flow-of-control messaging and pauses. JVM bloat or frequent message retransmissions are an indication that cache events from producers are overrunning consumers.

	## <a id="udp_comm__section_FB1F54A41D2643A29DB416D309ED4C56" class="no-quick-link"></a>UDP Retransmission Statistics

	<%=vars.product_name%> stores retransmission statistics for its senders and receivers. You can use these statistics to help determine whether your flow control and fragment size settings are appropriate for your system.

	The retransmission rates are stored in the DistributionStats `ucastRetransmits` and
	`mcastRetransmits`. For multicast, there is also a receiver-side statistic `mcastRetransmitRequests`
	that can be used to see which processes aren't keeping up and are requesting retransmissions. There
	is no comparable way to tell which receivers are having trouble receiving unicast UDP messages.