Listening vs. Connection Sockets
When a client makes a socket connection, there is only one socket involved: the "connection socket". But on the server side, there are actually two sockets: a "listening socket" and a "connection socket". The server starts by creating a "listening socket" and "binding" it to a protocol, address and port number. Then it "listens" on this socket for a client connection. The act of accepting the connection creates a new "connection socket" used for the duration of the connection. The listening socket then may or may not be closed, depending on the design of the server.
The A-Shell TCP subroutines encapsulate these details, making it appear as if there was only one socket. But in reality, it internally creates a listening socket, and then closes it after accepting a connection and returning the connection socket to the caller. Because it closes the listening socket, the port becomes available again for another process (or the same process) to again listen on the original port.
A single program could actually support multiple socket connections, all on the same port. This is not of much practical significance, though, since the subroutine blocks while waiting to accept a connection (and thus would be unable to service the existing connections during that time.) To service multiple concurrent connections effectively, you generally need multiple server processes.
