In network programming, must the accepting end close both sockets?

I raised a question earlier, and one of the answers involved another question.

That is to say, in general, the accepting end should create two sockets to establish the accepting end. like this:

Python

from socket import *
sockfd = socket(...)
# ...
client_sockfd, addr = sockfd.accept()
# ...
client_sockfd.close()
sockfd.close()

C

int sockfd, client_sockfd;
sockfd = socket(...);
// ...
client_sockfd = accept(sockfd, ...);
// ...
shutdown(client_sockfd, 2);
shutdown(sockfd, 2);
close(client_sockfd);
close(sockfd);

<hr>

So can we skip the task of creating the client_sockfd variable? like this:

Python

sockfd = socket(...)
# ...
sockfd, addr = sockfd.accept()
# ...
sockfd.close()

C

int sockfd;
struct sockaddr_in server, client;
socklen_t client_size = sizeof(client);
sockfd = socket(...);
// ...
sockfd = accept(sockfd, (struct sockaddr *)&client, &client_size);

Or it could be like this:

Python

sockfd = socket(...)
# ...
client_sockfd, addr = sockfd.accept()
sockfd.close()
# ...
client_sockfd.close()

C

int sockfd = socket(...);
int client_sockfd;
// ...
client_sockfd = accept(sockfd, ...);
shutdown(sockfd, 2);
close(sockfd);
// ...
shutdown(client_sockfd, 2);
close(client_sockfd);

As shown in the above code, can we use only one socket to complete the accepting end of the entire network programming? Is there any problem with this? (At least I didn't have any problems writing the program like this myself)

You are always creating two sockets: the server socket and the first accepted client socket. When you close them is up to you.

Using the same name for both in Python will still close the server socket (eventually) because the object reference count goes to zero, but in C you leak the socket.

> So can we skip the task of creating the client_sockfd variable?

For connection-oriented protocols such as TCP, no. The two sockets involved on the receiving side of such a service are of different kinds and serve different purposes, both required.

The socket that (in C) you create via the socket() function and use with the accept() function is often called a "server socket". It's job is to wait for incoming connection requests, and when it accepts one, to prepare an endpoint for communication with that request's remote peer. The resulting endpoint is represented by the second (and third, and fourth ...) socket, obtained via successful calls to accept().

You use the server socket to accept connections, potentially having multiple active connections at the same time, and you use each of the others ("peer sockets", if you like) to communicate with a specific client. Closing a peer socket terminates the connection with the associated remote peer. Closing the server socket makes the system stop accepting new connections at its address / port.

You propose this alternative:
>
> int sockfd;
> struct sockaddr_in server, client;
> socklen_t client_size = sizeof(client);
> sockfd = socket(...);
> // ...
> sockfd = accept(sockfd, (struct sockaddr *)&client, &client_size);
>
That's not technically wrong, but as soon as you assign the result of accept() to variable sockfd, you no longer have access to the server socket (supposing you did not store its file descriptor in another variable, which would moot the question). This is a resource leak. Moreover, it prevents you from accepting any subsequent connections at the designated address / port. Until the process terminates (if then), you will not even be able to create a new server socket for that port, as the existing one will be in the way.

All of this is different for datagram-oriented sockets -- there are no connections to accept(), and no inherent distinction between server sockets and peer sockets for such protocols. But based on the appearance of accept() calls in your example code, that's not what you are asking about.

In your first example

from socket import *
sockfd = socket(...)
# ...
client_sockfd, addr = sockfd.accept()
# ...
client_sockfd.close()
sockfd.close()

sockfd is the descriptor for the listener. It can be re-used.
After closing client_sockfd, you can accept again.

E.g.

from socket import *
sockfd = socket(...)
while not is_finished:
   client_sockfd, addr = sockfd.accept()
   # ...
   client_sockfd.close()
sockfd.close()

You can accept more than one socket (into different fd variables), and talk with multiple clients. However, this requires some concurrent programming.

I'm not sure if there is a "problem", but it seems relevant to explain whats going on here:

When you call sockfd.accept() it blocks until a connection comes in. When one does come in it returns another socket which "represents" the connection, and can be used to send and receive data on the connection. The reason for the multiple calls to socket.close() is that in your first example client_sockfd.close() only closes the connection. You can still call sockfd.accept() again to receive another connection, and many socket servers use socket.accept() in a while loop. Calling sockfd.close() will close sockfd, usually when no further connections (calls to sockfd.accept()) need to be made.