New post
Discussion (6)1
Log in or sign up to continue
Dhinupa Weerathunga · Mar 12, 2020
  • Checking for dead peers

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.

1 0
Cedric Daniels · Mar 12, 2020

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. 

0 0
Kevin Johnson · Mar 16, 2020

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. 

0 1
Alexey Maslov · Mar 17, 2020

Just adding 2c to Kevin's reply.

Most hosts that support TCP also support TCP Keepalive  

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.:

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 keepalive time to 60 seconds
/POLLDISCON to switch on TCP probes.

0 0