从套接字返回的文件描述符大于FD_SETSIZE

Question

I have a problem where the returned file descriptor would gradually increase to be a number larger than FD_SETSIZE .

My tcp server is continually shutdown which requires my client to close the socket and reconnect. The client will then attempt to reconnect to the server by calling socket to obtain a new file descriptor before calling connect .

However it appears that everytime I call socket the file descriptor returned is incremented and after a certain amount of time it becomes larger than FD_SETSIZE , which is a problem where I use select to monitor the socket.

Is it ok to reuse the first file descriptor returned from socket for the connect call even though the the socket was closed? Or is there other workarounds?

Reconnect code (looping until connected):

int s = getaddrinfo(hostname, port, &hints, &result);    
if (s != 0) { ... HANDLE ERROR ...}
...
struct addrinfo *rp;
int sfd;
for (rp = result; rp != NULL; rp -> ai_protocol)
{
    sfd = socket( rp->ai_family, rp->ai_sockettype, rp->ai_addrlen);
    if (sfd >= 0)
    {
       int res = connect(sfd, rp->ai_addr, rp->ai_addrlen);
       if (res != -1)
       {
          _sockFd = sfd;
          _connected = true;
          break;   
       }
       else
       {
          close (sfd);
          break; 
       }
    } 
}
if (result != NULL)
{
    free(result);
}

Read Message code:

if (_connected)
{
   ...
   retval = select(n, &rec, NULL, NULL, &timeout);
   if (retval == -1) 
   {
      ...
      _connected = false;
      close(_sockFd);      
   }
   else if (retval)
   {
      if (FD_ISSET(_sockFD, &rec) == 0)
      {
         ....
         return;
      }

      int count = read(...)

      if (count)
      {
         ....
         return;
      }
      else
      {
         ....
         _connected = false;
         close(_sockFd);
      } 
   }
}

Answer 1

You're not closing the socket if the connect fails. So it remains open, occupying an FD, so next time you call socket() you get a new FD. You're also not breaking out of your loop when connect() succeeds, which is another leak. You're also not checking the result of read() for -1.