Question: 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);   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)

Answer:  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.