KB Article #178712
CFTH22E NPART=MY_PARTNER rejected DIAGI=416 / NCR=416 NCS=MAXCNX
Problem
CFTH22E NPART=MY_PARTNER rejected DIAGI=416
NCR=416 NCS=MAXCNX
Randomly, CFT activity becomes slower and slower until freezing due to a lot of errors DIAGI=416
Resolution
Executing more transfers in parallel (each to a different partner) than the number of configured connections, Transfer CFT raised a lot of unexpected connection error messages: "NCR=416 NCS=MAXCNX".
To prevent such error, a new feature called Network Resource Depletion Prevention (NRDP) has been introduced.
FEATURE:
Network Resource Depletion Prevention (NRDP).
DESCRIPTION:
Configuring more network connections (say MAXCNX) than simultaneous file transfers (say MAXTRANS) is not always enough to ensure that MAXTRANS transfers can proceed simultaneously at any time.
The main reasons that explain this fact are the following:
1) File Transfers are performed over Protocol Sessions.
2) Each Protocol Session use a Network Connection.
3) Session termination requires exchanges, thus time, over its associated Network Connection.
4) Protocol Sessions establishment can be very costly (TLS for example).
5) CFT requester side tries to start all active transfers up to MAXTRANS regardless the
actual number of Network Connections used.
Because of reason #1 and #2, the number of sessions is at least equal to the number of
simultaneous transfers.
Because of reason #3, there can/does exist intervals of time where sessions with no active
transfer exist. Let's call such sessions "idle" sessions.
That leads sometime to a number of Sessions greater to the number of transfers.
Because of reason #4, it is advisable to be able use Sessions for more that a single transfer
when possible. To allow this, Sessions are not terminated immediately after a transfer ends, but after a configurable delay. Those idle sessions can be reused for subsequent transfers.
This can lead to a number of established Sessions significantly or even far larger that the
number of active Transfers when the number of idle sessions is high.
When the NRDP feature is enabled (see below for the configuration), CFT detects the situations
where existing idle sessions may prevent new transfers that require new sessions from being
started.
In such situations, CFT prevently close as softly as possible those idle sessions in order to
allow the new transfers to be started quickly.
This feature is only effective when the number of simultaneous connections (MAXCNX) is often
reached while the actual number of transfers is less the MAXTRANS. When such situation occurs,
log messages CFTN09E can flood the log and the behaviour of CFT can be adversely affected.
An example of such log message looks like the following:
CFTH09E Network connect request local error <PART=PARIS0805 NCR=416 NCS=MAXCNX NET=TCP>
CONFIGURATION:
UCONF:
cft.server.nrdp_enable
type = boolean No Yes
default = No
help = Enable prevention of network resource depletion.
cft.server.nrdp_conn_retry_delay_min
type = int
default = 1
help = Connection retry delay min in seconds when network resource depletion is detected.
cft.server.nrdp_conn_retry_delay_max
type = int
default = 5
help = Connection retry delay max in seconds when network resource depletion is detected.
PARAM:
This feature only apply to TCP/IP network and requires for a given class the configuration
of a CFTNET object that allows OUTGOING or both OUTGOING and INCOMING connections with
MAXCNX >= MAXTRANS.
A value a MAXCNX significantly larger than MAXTRANS can help especially when the number of
INCOMING connections can be high.
A value of MAXCNX 10% to 20% larger that MAXTRANS should be ok in most situations.
LOG MESSAGES:
1) CFTN05I Network resource depletion prevention enabled for class %d
2) CFTN06I No network class suitable for resource depletion prevention activation
Those messages are only printed to the log when the cft.server.nrdp_enable UCONF variable is true.
The message #1 indicates that a CFTNET object in this class follow the requirements for the feature
to apply to this class (i,e: type=TCP, maxcnx >= MAXTRANS, call=OUT or call=INOUT).
The message #2 indicates that no CFTNET object following the requirements for the feature to
apply was found for any class.
ALGORITHM:
Given the value of MAXTRANS and the MAXCNX of the selected CFTNET object of a class, a THRESHOLD is
computed as follows: THRESHOLD = (MAXCNX+MAXTRANS)/2
For example, if MAXCNX = 450 and MAXTRANS = 400, then THRESHOLD=425
Let's call NBCNX the current number of connections and NBTRANS the current number of transfers.
When NBCNX >= THRESHOLD (in our example: NBCNX >= 425 with MAXTRANS=400 and MXCNX=450) and
in order to actually perform the NBTRANS transfers new sessions must be established.
CFT prevently close idle connections in order to reduce NBCNX and defer the network connection request for new sessions until NBCNX <= THRESHOLD