Closing "established" socket that is stale

[Tod Wiederholt]

I have a situation where an application group wrote a java application that builds listener sockets. These sockets serve as connection points for remote customers to be able to interact with the application, the problem is that when a connection is severed without notifying our server via a tcp fin packet then our server thinks the connection is still established. The developers cannot find a way to force the stale connection closed without stoping and starting the entire JVM, which affects every other connection that is working fine.

So, what I am wondering is there anyone that has a utility or C code that would be able to get the socket descriptor information from the kernel when provided with the IP and port information. Using this socket descriptor, then be able to force the connection into a fin_wait2 state so that the OS will clean up the connection without having to take the rest of the application down.

[Brian Bergstrand]

There's really not much you can do. These "stale" connections will eventually go away on their own after a certain timeout period (I've seen from 20 minutes to over an hour).

Alternatively, you could have your app keep track of all connections and periodically try to send some data to each. If the link is down, then an error would be returned and your app could clean up. Of course, this depends on whether the application layer protocol you are using allows superfluous data.

I don't think it would be possible for one userland process to close the sockets belonging to a different process. I think you would need a kernel mod to do that.

HTH.

[Tim Sanko]

I am an old socket programmer and have this bit of advice. Explain that there needs to be activity on a socket, and write it in C.

If activity ends, then the listener should be on an an acceped socket that can be closed with a shutdown.

This is an application problem, not an Admin problem, but I have your answer.

The socket number can be reopened
and then shutdown(int socket).

if SO_KEEPALIVE is set you can hold it open until the close is sent from the remote end.

I would actually complete my data transmissions and close the listener end if there is no response in 120 seconds.


Tim

[Tod Wiederholt]

Tim, thanks for your reply. First of all, yes I agree with you that this is an application issue but unfortunately for me the application folks do not know how to handle it.

I am curious, you say the connection can be reopened and then using the shutdown() function you can close it, but this is assuming you now the socket number. To my knowledge the only two places that information can be found is either in the program that opened it or in a kernel table, neither of which I know how to access. Can you please provide some examples of how to obtain this information?

[Brian Bergstrand]

Tim is saying to use shutdown() from within your app, not from another -- after you have detected the connection is down. Sounds like your application programmers need some network programming training.

Hacking up the system (with a kmod) or writing another app to fix the problems of your main one won't fix the root problem, it will just mask it and possibly introduce other problems.

[Tod Wiederholt]

Thanks to both of you for your replies but neither of them really provided any help. I have since come across some additional messages on the forum about ndd parameters (tcp_discon and tcp_discon_by_addr) that should do what I need. However I am not having any luck getting them to work. Either way, I have created a new thread with this question.