Has anyone tried using the TCPKeepAlive function? I've been reading the documentation on this and it might be what I need to use. Any examples of how this is being used? thanks!
Keepalive can tell you when another peer becomes unreachable without the risk of false-positives. In fact, if the problem is in the network between two peers, the keepalive action is to wait some time and then retry, sending the keepalive packet before marking the connection as broken.
Preventing disconnection due to Network Inactivity
The most likely cause of this issue is a firewall timeout rule. Once the channel is open, wait until an event occurs and then communicate this to the other peer. Our connection has its scope, but it's unknown to the proxy. So when we finally send data, the proxy isn't able to correctly handle it, and the connection breaks up.Because the normal implementation puts the connection at the top of the list when one of its packets arrives and selects the last connection in the queue when it needs to eliminate an entry, periodically sending packets over the network is a good way to always be in a polar position with a minor risk of deletion.
I'm working with a 3rd party vendor call "OnBase" they have a setting they're unwilling to change on their side. If they don't receive any traffic in 3 hours, they will drop our connection. Causing a error on the Engine side. this mainly happens over the weekend. The majority of our offices are closed and traffic is very light. I was thinking this may be a possible solution to have this setup to prevent their side from disconnecting.
I am a guy who is enthusiastic with Networking and the good news is that, Yes I have used the TCPKeepAlive function. For you to understand this function you should be aware of a protocol named NAT or also known as Natting and TCP or also known as the Transmission Control Protocol.
A keepalive signal is often sent at predefined intervals, and plays an important role on the Web/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 Natting or the NAT enabled router can drop the connection after time out.
Since the only purpose is to find links that don't work or to indicate connections that should be preserved, keepalive messages tend to be short and not consume or take much of the Bandwidth.
There are 3 types of TCP KeepAlive functions available.
1.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. 2.Keepalive interval is the duration between two successive keepalive retransmissions, if acknowledgement to the previous keepalive transmission is not received. 3.Keepalive retry is the number of retransmissions to be carried out before declaring that remote end is not available
When two hosts are connected over a network via TCP/IP, TCP Keepalive Packets can be used to determine if the connection is still valid, and terminate it if needed.
Most hosts that support TCP also support TCP Keepalive. Each host (or peer) periodically sends a TCP packet to its peer which solicits a response. If a certain number of keepalives are sent and no response acknowledgement or also known as the (ACK) is received then the sending host will terminate the connection from its end. If a connection has been terminated due to a TCP Keepalive time-out and the other host eventually sends a packet for the old connection, the host that terminated the connection will send a packet with the Reset Flag or also known as the RST flag set to signal the other host that the old connection is no longer active. This will force the other host to terminate its end of the connection so a new connection can be established.
All this takes place in terms of a 3 Way hand shake procedure.
Typically TCP Keepalives are sent every 45 or 60 seconds on an idle TCP connection, and the connection is dropped after 3 sequential ACKs are missed.
This is just only a fraction of what I can tech you. There is much more on this like the HTTP keep alive and so on.
I hope that I have answered your question.
If there is anything else that you would like to know please feel free to ask me.
Hi Kevin! When you copy the external content to DC, please provide the link to the source, e.g. documentation, article or Wikipedia. For example this your comment is mostly copied from Wikipedia site. This is relevant, but please include the source.
Most hosts that support TCP also support TCP Keepalive
Besides, server application should support it. 3 hours keepalivetime setting is not typical; it sounds like your server app not tuned for keepalive support or doesn't support it at all.
In case of IRIS/Caché, you should explicitly set some options on connected server socket, e.g.:
start(port) // start port listener
s io="|TCP|"_port o io:(:port:"APSTE"):20 e quit
while 1 {
u io r x
u $p // connection is accepted: fork child process
j child:(:5:io:io)
}
child
use $p:(:/KEEPALIVE=60:/POLLDISCON)
...
/KEEPALIVE=60 to set keepalivetime to 60 seconds /POLLDISCON to switch on TCP probes.
Keepalive can tell you when another peer becomes unreachable without the risk of false-positives. In fact, if the problem is in the network between two peers, the keepalive action is to wait some time and then retry, sending the keepalive packet before marking the connection as broken.
The most likely cause of this issue is a firewall timeout rule. Once the channel is open, wait until an event occurs and then communicate this to the other peer. Our connection has its scope, but it's unknown to the proxy. So when we finally send data, the proxy isn't able to correctly handle it, and the connection breaks up.Because the normal implementation puts the connection at the top of the list when one of its packets arrives and selects the last connection in the queue when it needs to eliminate an entry, periodically sending packets over the network is a good way to always be in a polar position with a minor risk of deletion.
I'm working with a 3rd party vendor call "OnBase" they have a setting they're unwilling to change on their side. If they don't receive any traffic in 3 hours, they will drop our connection. Causing a error on the Engine side. this mainly happens over the weekend. The majority of our offices are closed and traffic is very light. I was thinking this may be a possible solution to have this setup to prevent their side from disconnecting.
Hello there Cedric,
I am a guy who is enthusiastic with Networking and the good news is that, Yes I have used the TCPKeepAlive function.
For you to understand this function you should be aware of a protocol named NAT or also known as Natting and TCP or also known as the Transmission Control Protocol.
A keepalive signal is often sent at predefined intervals, and plays an important role on the Web/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 Natting or the NAT enabled router can drop the connection after time out.
Since the only purpose is to find links that don't work or to indicate connections that should be preserved, keepalive messages tend to be short and not consume or take much of the Bandwidth.
There are 3 types of TCP KeepAlive functions available.
1.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.
2.Keepalive interval is the duration between two successive keepalive retransmissions, if acknowledgement to the previous keepalive transmission is not received.
3.Keepalive retry is the number of retransmissions to be carried out before declaring that remote end is not available
When two hosts are connected over a network via TCP/IP, TCP Keepalive Packets can be used to determine if the connection is still valid, and terminate it if needed.
Most hosts that support TCP also support TCP Keepalive. Each host (or peer) periodically sends a TCP packet to its peer which solicits a response. If a certain number of keepalives are sent and no response acknowledgement or also known as the (ACK) is received then the sending host will terminate the connection from its end. If a connection has been terminated due to a TCP Keepalive time-out and the other host eventually sends a packet for the old connection, the host that terminated the connection will send a packet with the Reset Flag or also known as the RST flag set to signal the other host that the old connection is no longer active. This will force the other host to terminate its end of the connection so a new connection can be established.
All this takes place in terms of a 3 Way hand shake procedure.
Typically TCP Keepalives are sent every 45 or 60 seconds on an idle TCP connection, and the connection is dropped after 3 sequential ACKs are missed.
This is just only a fraction of what I can tech you. There is much more on this like the HTTP keep alive and so on.
I hope that I have answered your question.
If there is anything else that you would like to know please feel free to ask me.
Regards.
Hi Kevin! When you copy the external content to DC, please provide the link to the source, e.g. documentation, article or Wikipedia. For example this your comment is mostly copied from Wikipedia site. This is relevant, but please include the source.
Just adding 2c to Kevin's reply.
Besides, server application should support it. 3 hours keepalive time setting is not typical; it sounds like your server app not tuned for keepalive support or doesn't support it at all.
In case of IRIS/Caché, you should explicitly set some options on connected server socket, e.g.:
/KEEPALIVE=60 to set keepalive time to 60 seconds
/POLLDISCON to switch on TCP probes.
FYI but Cedric is dealing I believe with a Business Service. So his only option roght now is to mod the library code