Question How do I get a tcp connection to close when not used ?

Jun 15, 2022
4
0
10
I need a connection to close or reset when it’s no longer communicating. Is there a setting or registry value that I can use?
 

USAFRet

Titan
Moderator
I need a connection to close or reset when it’s no longer communicating. Is there a setting or registry value that I can use?
Is this related to this?
 
Jun 15, 2022
4
0
10
Is this related to this?

yes. I realized the connection wasn’t closing. It closed when I made edits to the settings
 
Are you sure it is a TCP connection.

The standard way these work is the client send a syn message. The server responds with a syn ack and the client sends a ack message in response.

At this point the connection is open and either side can then send messages and the other side will send acks in response.

Either side can also close the session either cleanly by sending FIN message which is also acknowledged. It can also just force a close with a reset.

So what in your session does not follow this pattern. In general the software application does not know anything about these details. It just sends data and all the tcp stuff just happens. The application in general dose not actually generate the tcp messages that is a function more of the OS.

If you are using UDP then the concept of session is all in the application.
 
Jun 15, 2022
4
0
10
Are you sure it is a TCP connection.

The standard way these work is the client send a syn message. The server responds with a syn ack and the client sends a ack message in response.

At this point the connection is open and either side can then send messages and the other side will send acks in response.

Either side can also close the session either cleanly by sending FIN message which is also acknowledged. It can also just force a close with a reset.

So what in your session does not follow this pattern. In general the software application does not know anything about these details. It just sends data and all the tcp stuff just happens. The application in general dose not actually generate the tcp messages that is a function more of the OS.

If you are using UDP then the concept of session is all in the application.

I’m not very good with networking. All I know is what’s in the software manual. It says the unit will establish a connection to the tcp server. A config message must then be sent in less than one second after the connection has been established. I did get a look at the code and it has a loop function which waits until connection exists and then sends the message.

From looking at the software log I can see it is sending the message as soon as the software starts implying the connection already exists. When I edit the Ethernet settings , it must reset the connection. Because the next time I run it it takes 10-20 seconds before sending the message and the message is accepted.

I need the connection to close or reset when it’s finished sending messages so that it will work properly the next time the software is run.
 
Is there no support for the software to ask this question. There are way too many possibilities that can cause this most of which are in the application.

I "configuration" message is a application concept not a network concept.

You can see what the actual network is doing by using wireshark. You can filter it to just the ip and port being used by your application. You should be able to see exactly when the session are opened and closed.

What you are doing by say unplugging ethernet is not closing the session....ie you are sending no messages to the server. So on your side you just delete all the session information with no communication. The server side still has the session open. It likely has some kind of timeout where it hears nothing from your side before it finally closes it. Depending on the application if a new session is attempted to be opened it may or may not just immediately close the first one.

This is not something you set in windows or the nic. I suspect the problem is on the server side but more it is the application is not designed properly to handle a abnormal termination of a session.