Can anyone tell me what the option “Save client IP and port to driver control” under the Thread prop., Protocols, Multiserer config. does? We are troubleshooting a situation where cl fails to close established connections from a client even after significant inactivity.
Any message received into a multi-server thread has a connection ID that you will find in the driver control metadata field of every message received. In order to send a reply message to the system that sent the received data message you must put the correct connection ID into the driver control metadata field of the reply message.
The check box for client IP and port causes the engine to add keys for the address and port of the connecting system to the driver control metadata field. You can’t prevent anyone from connecting to a multi-server thread (that is without using security) but you could look at the ip address and port of the connecting system and refuse to process messages from unknown addresses.
This wouldn’t be the cause of the problem you describe though. Why would you expect Cloverleaf to close a connection? Did you check “close after write”?
Greg, as I understand socket connections, if no keepalive is recieved on a connection in the default of 2 hours, Windows is supposed to close the connection.
I wouldn’t call myself a socket expert so I’m only speaking from my experience. In a project were we tried to maintain a cloverleaf to cloverleaf tcpip connection accross the internet we got some odd results. We would find that after some period of time the sender would try to send a transmission but the receiver would never get it and the sender would eventually timeout waiting for replies. The protocol status on both sides was up.
We had to surmise that on one of the hops along the way through the internet one of the switches must have timed out our connection. When that happens, it doesn’t inform the application so Cloverleaf doesn’t know to disconnect.
I wasn’t aware that Windows would take action on a port without an event but I am aware that a switch or a hub along the way might do something to the connection.
.
.