I have questions about the time limit for the tcp binding socket in server side.
In my survey, I found if the tcp client socket send the close message to the server, the client will enter to TIME_WAIT state last for 2 MSL.
If the client socket connect to server, but didn't send the close message. And it's also not send any data to server. Do the server side socket bind this socket continuously and not to close it forever until server down?
Is there a limited timeout for the tcp binding socket in the server side?
Thank you for your read and hopefully for your reply.
No there's no time limit. A connected socket stays connected until the connection is closed.
If you want to make sure that both ends of a connection is still alive, you could add such a "is alive" message to your protocol, and if the the other doesn't answer within some time limit you can close the connection. There is also the builtin functionality of SO_KEEPALIVE socket option which will handle this for you, but the default timeout is two hours for that.
Related
Okay, I've read this post in search for the right answer, but it does not seem to serve my purpose.
This Question
Now, getting to the trouble:
I have a conventional client-server architecture in C (all sockets are non-blocking), where the server is listening for incoming connections and the client tries to connect. The first connect succeeds and everything goes on just fine until I press Ctrl + C on my server.
The client side of the code detects that the connection is lost and arms a retry timer.
The client code is supposed to try a reconnect on the server again and again by using the POSIX interval timers on each timer popping. It however, does not close the socket or start out afresh. Now, every time it retries the connection, the connect() returns
Transport endpoint is already connected
Even after restarting the server, which uses the SO_REUSEADDR and successfully starts, the connect does not complete.
One thing that I will need to implement is the signal handler on the server for the shutdown on Ctrl+C.
But still, do I need to close the socket descriptor on the client side and start afresh every time a disconnect happens, or is there a way out of this?
sockets cannot be reused.
Once the connection a socket served has gone down in both directions, the socket is unusable.
close() the client socket on loss of connection and create a new socket for a new connection.
Update (based on the comments below):
In the OP's case one side (the server side) went down (by means of the server process ending). This implies all sockets held by this process are implicitly close()ed and therefore shutdown() in both directions.
I want to make a TCP Socket that doesn't connect to the host but instead sends data without connecting... Is that possible with the Python 3 Socket module?
TCP sockets always need to be connected before sending data. Establishing the connection involves an actual packet exchange with the peer, i.e. the TCP 3-way handshake. This is also means that the connect can fail if the target cannot be reached. This is not specific to Python but specific to how TCP sockets work.
With UDP a socket can be connected but does not need to be. Connecting a UDP socket essentially just sets the target on the local socket but does not involve any actual data transfer. This also means that the connect will usually not fail even but a later data transfer might not be able to reach the target.
In python, tcp connect returns success even though the connect request is in queue at server end. Is there any way to know at client whether accept happened or in queue at server?
The problem is not related to Python but is caused by the underlying socket machinery that does its best to hide low level network events from the program. The best I can imagine would be to try a higher level protocol handshake (send a hello string and set a timeout for receiving the answer) but it would make no difference between the following problem:
connection is queued on peer and still not accepted
connection has been accepted, but for any other reason the server could not process it in allocated time
(only if timeout is very short) congestion on machines (including sender) and network added a delay greater that the timeout
My advice is simply that you do not even want to worry with such low level details. As problems can arise server side after the connection has been accepted, you will have to deal with possible higher level protocol errors, timeouts or connection loss. Just say that there is no difference between a timeout after connection has been accepted and a timeout to accept the connection.
If connect returns and there is no error, the TCP 3-Way Handshake has taken place successfully.
Client: connect sends a SYN (and blocks)
Server: (blocking on accept) sends a SYN,ACK
Client: connect sends an ACK
After 3, connectgives control back to you on the client side and accept also gives control back to the caller on the server side.
Of course, if the server is fully loaded, there is no guarantee that the wake-up of accept means actual processing of the request, but the fact that connect has woken up and returned with no error is a guarantee of having successfully set-up the TCP connection.
Packets can be sent.
For a good explanation see for example:
https://www.ibm.com/developerworks/aix/library/au-tcpsystemcalls/index.html
And head to the The 3-way TCP handshake section
I have a fairly general question about best practice when using socket to communicate with remote hardware: should the socket be closed after each message is sent or left open?
To illustrate this question: I'm using python (and socket) to interface with a remote piece of hardware. Typically, I'll send a command to the device every 30 seconds or so, receive the reply and then wait ~ 30 seconds.
At present I'm doing:
# Open socket
self.sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
self.sock.settimeout(10)
self.sock.connect((self.host_ip_address, self.port))
# Send Message
self.sock.send(my_command)
# Receive Reply
data = self.sock.recv(1024)
# Close socket
self.sock.shutdown(socket.SHUT_RDWR)
self.sock.close()
I wonder if this advisable, or should I simply leave the socket open for the duration of my session with the device (say ~ 1hr). Would this be robust?
Any tips / pointers welcomed thanks!
This is robust as long as you exchange data from time to time over your socket. If not, a Firewall/NAT can decide that the TCP connection is broken and stop routing the TCP packet.
I'm running tcp server in C and tcp client in python. Both runs in different hardware. Let us consider Hardware A as server and Hardware B as client. If i quit the execution in Hardware A gracefully, it will send a empty packet to client (Hardware B), so that client comes to know connection is disconnected. But instead of quitting directly, i directly power off the Hardware A. Now client (Hardware B) doesn't get notified with empty packet that connection is disconnected. How to handle this scenario ? How does the client know about the disconnection when Hardware A is powered off ?
If the TCP connection is idle, the client won't know for a long time (perhaps never).
If the client is trying to send any data to the server, then the client's TCP packets will stop being acknowledged by the server when the server is powered down; the client's TCP stack will try to resend the packets a few times, but within a couple of minutes it will give up and unilaterally close the TCP socket. At that point the socket will select() ready-for-read, and the next call to read() on the socket will return 0 indicating that the connection is closed.
Therefore if you want to handle this scenario gracefully, the thing to do is periodically send some dummy data on the socket (i.e. something that the server will simply ignore if it receives it). That will be sufficient to ensure that the client's local TCP stack detects and handles the problem.