CODEWITHSUNDEEP
csocketsrecv
user1495948
user1495948

Reputation: 75

Method to handle bad file descriptor error

Scenario:
Connection is established between client and server.The client side connections are closed and client is destroyed. At the server side some of the connections closed are detected but some are not.So there are socket descriptor which are like dangling pointers.Select on these returns Bad file descriptor error but it is not possible to find the invalid fd .

Question: In the above scenario, where the client connection does not exist how should I handle these BAD FILE DESCRIPTORs .Can I call recv() on these ?

Upvotes: 2

Views: 10018

Answers (2)

ciphor
ciphor

Reputation: 8288

I believe you messed up different situations.

If a connection is closed at client side, and you call select() on the server side socket, FD_READ will be triggered and recv() will return zero, then you can close the socket at server side.

If a connection is lost and the server does not receive the FIN signal, you need to have heartbeats between client&server as well as a timer on each server side socket to detect the TCP half open situation.

The "bad file descriptor" error only happens when you call API on an already closed socket.

Upvotes: 1

Jonathan Leffler
Jonathan Leffler

Reputation: 753645

The signature for select() is:

int select(int nfds, fd_set *restrict readfds,
           fd_set *restrict writefds, fd_set *restrict errorfds,
           struct timeval *restrict timeout);

Doesn't the errorfds set give you a list of descriptors which generated an error condition, such as EBADF?

You can call recv() or any other function that takes a file descriptor with the bad file descriptor; you will likely get back an EBADF error from the function called (unless it detects a different error condition before detecting EBADF).

Upvotes: 1

Related Questions