A keepAlive (KA) is a message sent by one device to another to check that the link between the two is operating, or to prevent this link from being broken.
A keepalive signal is often sent at predefined intervals, and plays an important role on the Internet. After a signal is sent, if no reply is received the link is assumed to be down and future data will be routed via another path until the link is up again. A keepalive signal can also be used to indicate to Internet infrastructure that the connection should be preserved. Without a keepalive signal, intermediate NAT-enabled routers can drop the connection after timeout.
Since the only purpose is to find links that don't work or to indicate links that should be preserved, keepalive messages tend to be short and not take much bandwidth. However, their precise format and usage terms depend on the communication protocol.
Transmission Control Protocol (TCP) keepalives are an optional feature, and if included must default to off.[1] The keepalive packet contains null data. In an Ethernet network, a keepalive frame length is 60 bytes, while the server response to this, also a null data frame, is 54 bytes.[citation needed] There are three parameters related to keepalive:
Keepalive time is the duration between two keepalive transmissions in idle condition. TCP keepalive period is required to be configurable and by default is set to no less than 2 hours.
Keepalive interval is the duration between two successive keepalive retransmissions, if acknowledgement to the previous keepalive transmission is not received.
Keepalive retry is the number of retransmissions to be carried out before declaring that remote end is not available.
An OpenEdge application that employs the AppServer is vulnerable to failures in the persistent TCP/IP connections that are established between the client and the AppServer. These connections can fail for the following reasons:
A keepalive signal is often sent at predefined intervals, and plays an important role on the Internet. After a signal is sent, if no reply is received the link is assumed to be down and future data will be routed via another path until the link is up again. A keepalive signal can also be used to indicate to Internet infrastructure that the connection should be preserved. Without a keepalive signal, intermediate NAT-enabled routers can drop the connection after timeout.
Since the only purpose is to find links that don't work or to indicate links that should be preserved, keepalive messages tend to be short and not take much bandwidth. However, their precise format and usage terms depend on the communication protocol.
TCP keepalive
Transmission Control Protocol (TCP) keepalives are an optional feature, and if included must default to off.[1] The keepalive packet contains null data. In an Ethernet network, a keepalive frame length is 60 bytes, while the server response to this, also a null data frame, is 54 bytes.[citation needed] There are three parameters related to keepalive:
Keepalive time is the duration between two keepalive transmissions in idle condition. TCP keepalive period is required to be configurable and by default is set to no less than 2 hours.
Keepalive interval is the duration between two successive keepalive retransmissions, if acknowledgement to the previous keepalive transmission is not received.
Keepalive retry is the number of retransmissions to be carried out before declaring that remote end is not available.
Does OpenEdge AppServer support KeepAlive?
An OpenEdge application that employs the AppServer is vulnerable to failures in the persistent TCP/IP connections that are established between the client and the AppServer. These connections can fail for the following reasons:
Category of Error
|
Description
|
closed connection
|
The client or server application has purposely closed the
connection.
|
process abort
|
The client or server application process has aborted, but
the TCP/IP stack on the host machine is still functional.
|
host machine crash
|
The machine where the client or server application is
running has crashed. The TCP/IP stack
on the crashed machine is not functional.
|
network failure
|
The network between the client and server application host
machines has failed. The TCP/IP stacks
on the host machines are still functional, but no route through the network
exists between the two host machines.
|
In the first two cases (closed connections or process abort),
TCP/IP notifies the remaining application[1],
allowing it to react appropriately. In
the latter two cases (machine crash or network failure), however, the failures
are not immediately detected by TCP/IP, leaving the application unaware that a
problem has occurred[2]. When this happens, the application is often
stalled, consuming system resources and unable to perform additional work.
The features described in this document attempt to improve
the ability of the stalled application to detect these “undetected” network
failures and react to them. The specific
use cases addressed by the Distributed Component Awareness (DCA) AppServer Keepalive
protocol are described below, followed by a description of the protocol.
[1]
The notification usually comes in the form of a close event when the
application attempts to read data from the connection.
[2]
Actually, a subcase of the ‘host machine crash’ scenario exists. If the host machine crashes and restarts
before the TCP/IP keepalive interval expires, then an attempt to send data to
that machine will result in an immediate error as the old connection is unknown
to restarted TCP/IP stack. For purposes
of simplicity, we will ignore this case.
To address the problems described above, OpenEdge has introduced the AppServer Keepalive (ASK) Protocol. This protocol actually consists of two features, referred to as the serverASK and clientASK protocols. The serverASK protocol allows the AppServer to detect failures of the client, while the clientASK protocol allows the client to detect failures of the AppServer.
It should be noted that these two protocols operate independently of one another, and therefore may be deployed as such .
Also Refer:
http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html
To address the problems described above, OpenEdge has introduced the AppServer Keepalive (ASK) Protocol. This protocol actually consists of two features, referred to as the serverASK and clientASK protocols. The serverASK protocol allows the AppServer to detect failures of the client, while the clientASK protocol allows the client to detect failures of the AppServer.
It should be noted that these two protocols operate independently of one another, and therefore may be deployed as such .
Also Refer:
http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html
No comments:
Post a Comment