TCP/IP problem: closes on client side, not on server side, can't reconnect!

Question

Hey folks. I have a Java servlet that establishes a TCP/IP connection (via the Socket class) to a credit card processing company. Sometimes (usually early in the morning), for some reason the servlet starts timing out when using the socket (read timeouts), and the servlet responds by attempting to close() the socket, then re-open. The reopen doesn't work (no route to host).
The credit card processing company put a sniffer on their end, and they don't see anything when our reads time out or when we subsequently do a close(). Thus, they assume the connection is still established. When we try to open a new connection, our SYN packets do get through to them just fine, but they reply with RST packets because they think the prior connection is still established (thus they reject the new connection attempt)... but for us, that connection had gone dead.
They recommend we send FIN packets to them etc., i.e. that we do a proper TCP/IP close.... but if the connection suddenly goes dead to us, we can't do that... our close() attempts send absolutely nothing to them (no FIN packets, nothing at all).
Any ideas? Our servlet runs in Java 1.2 under BEA Weblogic 4.5.1 on an HP/UX box. I'm thinking that, after a long time (hours) with no data transferred, our socket times out somehow on our end only (the card company appears to have no such idle-timeout policy), and thus our read/write/close attempts send nothing to them (because the socket is now invalid), but of course the subsequent open attempt sends SYN's just fine. A search of the "weblogic.properties" file produces no apparent TCP/IP socket idle-timeout values to increase or eliminate.
Please help if you can... right now, the connection can be down for hours because of this (with many fruitless incidents of our open-attempt SYN's responded to with RST's), and we have to call the credit card processing company to have them reset the port, which allows our next open attempt to work.
Thanks!

Answer 1

Strange... You say:
Thus, they assume the connection is still established. When we try to open a new connection, our SYN packets do get through to them just fine, but they reply with RST packets because they think the prior connection is still established (thus they reject the new connection attempt)... but for us, that connection had gone dead.
According to me, normal TCP behavior shouldn't behave like that.
A connection is identified by the two ends. Each end is a pair of <IP><Port>... This pair is likely to be the same all the time on the server, but will change on the client. The first time you issue a connection to the server, you will have a TCP connection identified by <ClientIp><FreeLocalPort1>-<ServerIp><ServerListeningPort>. The second time you connect, another free local port will be used. The previous cannot be reused - either because still in use, or because of a kind of 'grace' period during which this port number cannot be reused (this is to prevent mis-interpretation of packets that might be delayed on the network - connection is in the state TIME_WAIT).
Therefore, I don't understand why the server replies with RST when your client tries to reconnect.
Unless it has nothing todo with the TCP layer itself... You will see the same RST packet if the server application itself (not the TCP layer) refuses the connection because of some logic that says 'only one connection per client host'. If the server didn't notice your first connection was dead, it is likely to refuse your second attempt. See what I mean?
Remember a TCP connection can be half-closed. This means that if your client closes the connection, the server won't be able to send you anything but can still read what you send. In this case, if the server sits waiting for your data, it will never detect the connection lost... This is why most tcp daemons start a timer when reading incoming data. After a predefined period of inactivity, they decide the connection is dead and will close their side of the pipe - the connection is now fully closed.
Hope it was clear (despites my poor English and the very late hour in the night ;-)
Can point you to more accurate TCP doc if needed.
-Bertrand