Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1831
  • Last Modified:

socket programming: keep connection alive

Hi,

I have an application that maintains an open connection to a server.
I have no control over the server, and sometimes when no action occurs in the socket in a long time the server closes the connection, that's the problem

Well I have the following options to maintain the socket open everytime:

1. I could set the KEEP ALIVE option by means of setsockopt. But AFAIK it sends a NO OPERATION packet when two hours have passed without activity and if I want to manipulate this, I have to change that OPTION in the whole system not in one  connection.

2. Before send the message, I could test if a socket is open, using getpeername or recv with MSG_PEEK. If the connection is closed, reopen it.
This option doesn't convince me enough. I will test this option after all.

3. I could have a way to test if no action has ocurred -in a specified time period- in the socket (it's a sender socket) by means of select for example and if this is the case, then send a NOP packet or doing some activity to avoid the server close mi connection. Its possible? do you have some sample code on this last idea???

4. The last: Use a thread to send packets each ten minutes for example on the open connection. I don't want this option.

Some comments???

thanks,

cero

P.D. sorry but english is not my first language
0
cero
Asked:
cero
  • 2
1 Solution
 
mtmikeCommented:
Setting the SO_KEEPALIVE socket option has a timeout of at least two hours. Some systems support the per-socket TCP_KEEPIDLE option that can be used to set this timeout. This is not very portable and only useable for TCP.

It's possible to implement keepalive by sending dummy packets at a given interval, but this doesn't sound very attractive to me. AFAIK you cannot send protocol-level NOP packets yourself.

I think the second option is the best one. You don't have to query the socket before sending though. Simply send the packet and try to reopen the connection when the send fails with EPIPE. This method has very little overhead since the reopening logic will be in the error-checking path.
0
 
ceroAuthor Commented:
Thanks,

Well the problem was that I was receiving SIGPIPE instead of EPIPE, and the signal was terminating my program, and when I read your comment I will look at "send" another time and in the flags I found MSG_NOSIGNAL for avoiding the signal SIGPIPE.

Points for you.

cero.
0
 
mtmikeCommented:
MSG_NOSIGNAL will work, but is not entirely portable. Another, more portable way is to ignore the pipe signal for all file descriptors using 'signal(SIGPIPE, SIG_IGN)'.
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now