Your confusion lies in thinking that a socket is identified by Server IP : Server Port. When in actuality, sockets are uniquely identified by a quartet of information:
Client IP : Client Port
and Server IP : Server Port
So while the Server IP and Server Port are constant in all accepted connections, the client side information is what allows it to keep track of where everything is going.
Example to clarify things:
Say we have a server at 192.168.1.1:80
and two clients, 10.0.0.1
and 10.0.0.2
.
10.0.0.1
opens a connection on local port 1234
and connects to the server. Now the server has one socket identified as follows:
10.0.0.1:1234 - 192.168.1.1:80
Now 10.0.0.2
opens a connection on local port 5678
and connects to the server. Now the server has two sockets identified as follows:
10.0.0.1:1234 - 192.168.1.1:80
10.0.0.2:5678 - 192.168.1.1:80
When you create a socket with socket()
, it has only a type and a protocol family. The ideal is to bind()
it to a local address:port too.
The error you mentioned normally happens when the last connection to the same host:port didn't have a graceful shutdown (FIN/ACK FIN/ACK). In these cases, the socket stays in TIME_WAIT
state for a certain period of time (OS dependent, but adjustable).
What happens then is when you try to connect()
to the same host and same port, it uses the default socket's name/address/port/etc, but this combination is already in use by your zombie socket. To avoid this, you can change the local address:port used to establish the connection by calling bind()
after the socket creation, providing the sockaddr
struct filled with your local address and a random port.
int main() {
int ret, fd;
struct sockaddr_in sa_dst;
struct sockaddr_in sa_loc;
char buffer[1024] = "GET / HTTP/1.1\r\nHost: www.google.com\r\n\r\n";
fd = socket(AF_INET, SOCK_STREAM, 0);
// Local
memset(&sa_loc, 0, sizeof(struct sockaddr_in));
sa_loc.sin_family = AF_INET;
sa_loc.sin_port = htons(LOCAL_RANDOM_PORT);
sa_loc.sin_addr.s_addr = inet_addr(LOCAL_IP_ADDRESS);
ret = bind(fd, (struct sockaddr *)&sa_loc, sizeof(struct sockaddr));
assert(ret != -1);
// Remote
memset(&sa_dst, 0, sizeof(struct sockaddr_in));
sa_dst.sin_family = AF_INET;
sa_dst.sin_port = htons(80);
sa_dst.sin_addr.s_addr = inet_addr("64.233.163.104"); // google :)
ret = connect(fd, (struct sockaddr *)&sa_dst, sizeof(struct sockaddr));
assert(ret != -1);
send(fd, buffer, strlen(buffer), 0);
recv(fd, buffer, sizeof(buffer), 0);
printf("%s\r\n", buffer);
}
UPDATE: As using a specific local port is a requirement, consider setting SO_LINGER
with l_onoff=1
and l_linger=0
so your socket won't block upon close
/closesocket
, it will just ignore queued data and (hopefully) close the fd. As a last resort you can adjust the TIME_WAIT
delay by changing the value of this registry key (highly discouraged!):
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpTimedWaitDelay
Best Answer
It assigns the "local" end's port number.
For a server socket, this is the ultimate way to go - it is exactly what is needed: have your socket be bound to port 80 for a web server, for example.
For a client socket, however, the local address and port is normally not of importance. So you don't
bind()
. If the server restricts its clients to maybe have a certain port number, or a port number out of a given range, you can usebind()
on client side as well.On the other hand, you might as well be able to
listen()
on a socket where you haven't calledbind()
(actually I'm not sure about that, but it would make sense). In this scenario, your server port would be random, and the server process would communicate its port via a different means to the client. Imagine a "double-connection" protocol such as FTP, where you have a control connection and a data connection. The port the data connection listens on is completely arbitrary, but must be communicated to the other side. So the "automatically determined port" is used and communicated.One example in Python: