Does the socket become unusable after connect () fails?

Question

In chapter 4, paragraph 4.3 of Stephen's "Socket: Networking API, Third Edition", the author states the following

"If connect fails, the socket is no longer usable and must be closed. We cannot call connect again on the socket." 

Does anyone know the reason for the above statement?

In my own experiments, I wrote a simple tcp client that will run on host A and on a simple tcp server that will run on host B. The tcp client will try to connect to the tcp server on host B forever.

So, I started the server on host B. I pulled the network cable from the host. Then I started the client on host A. After 9 unsuccessful attempts to connect to the same socket, I just connected the network wire back to the server. The client successfully and successfully sends messages at a speed of 80 fps.

In another experiment, I pulled a wire from the server host after a successful successful connection and the exchange of several million messages. Then, after a few minutes, I connected the wire and message flow resumed in the same slot.

Answer 1

POSIX 2001 says in the information section:

If connect() fails, the state of the socket is not indicated. Relevant applications should close the file descriptor and create a new socket before attempting to reconnect.

Thus, the passage you cited complies with this specification. The fact that it works on your computer does not mean that your program is portable.

Answer 2

This could be due to the connection manpage , which says:

Typically, connection-based protocol sockets can successfully connect() only once; Connectionless sockets can use connect() several times to change their connection.

This means that you cannot just reconnect the socket (read, TCP) based on the connection. However, I cannot say that this indicates a failed connect() , implying that we cannot process FD.

Resuming connections, if the connection was interrupted, is a TCP function that usually tries to do this.

Answer 3

To answer your specific question ...

Simply put, there are a large number of TCP implementations. While some may support the execution of another connect() call after failure, others will have status information that would make such an unreliable.

To be safe, there must be some kind of reset() operation that will return the socket to its original state. Since this was not included in the original (or any subsequent) TCP implementation, the only remaining option is to close and reopen.

The POSIX standard (and your book, which probably uses the POSIX standard as a reference), tells you to do just that to be able to work with all TCP / IP-compatible operating systems. Otherwise, a number of existing implementations would be invalidated.

In addition, new implementations can simplify their implementation without worrying about starting a new connection after an unsuccessful attempt; this leads to less code and fewer errors when filling in errors.

Answer 4

Are you sure that you are using the same socket and not the new socket that you are trying to connect to the same address as before?

Even if this is what you are doing, the fact that the particular OS you are experimenting with allows you to reuse a socket that could not connect, does not mean that all other OSs that implement the socket API (or earlier / later versions of the same OS) will be equally soft, so you run the risk of getting thinly non-portable code.

When you do that the API contract does not promise that you will work, it is not generally known what will happen. One possible reaction is that it seems to work - until the payment client tries to run your code on their machine.

How risky is the cost of close(socket); socket=socket(...); close(socket); socket=socket(...); in a rather rare error situation?