CODEWITHSUNDEEP
csockets
work.bin
work.bin

Reputation: 1108

Is the new connected socket returned by accept() always bound to the same port as the listening socket?

I tested this on my machine by creating new connections until failure. On my machine new connect()/accept() requests fail* at near 700 socket connections (SOCK_STREAM); at the client/server respectively, on the loopback IP address. However the socket file descriptor returned by accept(), so far, is always bound to the same port as the listening socket.

My question is - If this behaviour is true for all machines then why is accept() limiting connections by creating connected sockets bound only to the same port as the listening socket? Couldn't the number of connections the server can make be increased greatly if the new sockets were bound to random ports (like connect() does)?

Also, why is accept(sock_fd, NULL, NULL) failing with "EFAULT - The addr argument is not in a writable part of the user address space." after nearly 700 successful iterations of the same call?

Similarly, why does, connect() fail with "EFAULT - The socket structure address is outside the user's address space." after nearly 700 successful iterations of the same call?

* EFAULT - Bad Address (after both accept()/connect()).

Upvotes: 1

Views: 3145

Answers (2)

Matt
Matt

Reputation: 15081

why is accept() limiting connections by creating connected sockets bound only to the same port as the listening socket? Couldn't the number of connections the server can make be increased greatly if the new sockets were bound to random ports (like connect() does)?

It doesn't impose any limitations. A connected TCP socket's "address" should be viewed as four parameters: srcip, srcport, dstip, dstport. So there's absolutely no need to bind accept()'ed socket to a random port.

Also, why is accept(sock_fd, NULL, NULL) failing with "EFAULT - The addr argument is not in a writable part of the user address space." after nearly 700 successful iterations of the same call?

Well, it's about OS internals. The amount of resources for any user process may (and should be) limited. Read your OS developer manual or such.

Upvotes: 2

Stian Skjelstad
Stian Skjelstad

Reputation: 2335

When you are listening, all connections will have the same port in the accept end of the connection (that is what is used as an identifier initially in order to establish the connection).

The local port number for the connecting part if not defined with a bind() can be anything. For the localhost device, the numbers can probably be recycled very fast on some OS, since there is no real need for lingering state of the TCP.

When it comes to having MANY connections on the same time, the amount of connections possible is limited by resources in your operating system per process. For Unix/Linux, this limit can be adjusted, put it is not advised to make the amount of FDs higher than default if using select(), since the libc size of the FDSET usually matches the default number of filedescriptors available per process. One trick around this is to create the socket, fork out children and let the children call accept(). Then each children can have many connections (apache and squid use this kind of model), increasing the total amount of connections possible on the same server port.

Upvotes: 4

Related Questions