How to reject a socket connection?

[Suresh R]

I tried 'accept' followed by 'close'. But, this solutions seems to cause problems at times.

Basically, I 'select' on my socket descriptor (sd), and take in any connections on my server. After accepting 8 connections, I would'nt want to accept any more connections. So, I would 'accept' that 9th connection and immediately 'close' the returned fd. But, this does'nt seem to work always, because my subsequent call to 'select' on the 'sd', succeeds thinking that there is some connection to accept, which is not the case. I hope 'connect' does not automatically retry, if it receives a failure immediately after an accept. Is it possible that accept does'nt clean up the socket properly and is there someway we could manually force it?

The behaviour is not consistently observed -- it happens only in 1 out of 4 attempts.

I am using HPUX11.11. I tried, in vain, searching for patches on the similar lines. If anybody is aware of patch or an alternate solution for this, please share the same.

Thanks,
Suresh R

[Muthukumar_5]

We can use shutdown() instead of close() on this situation. close() will try to receive subsequent data's.

shutdown(sd,how) where,

If how is SHUT_RD, further
receptions will be disallowed.

set how=1 or how=SHUT_RD

It will stop the duplex connection and shutdown(s) the socket. The disadvantage is shutdown() will not do the graceful shutdown of socket(s).

But for your requirement, use shutdown(). It will do.

see shutdown(2) and close(2) man pages more.

[rick jones]

once you call accept(), that connection is no longer in the listen queue. when you call close, unless youve fiddled with SO_LINGER settings (don't) a graceful shutdown of the connection (exchange of FIN segments) is initiated.

now, before you have called accept(), the remote's connect() call will have completed, couple that with connect() not doing any automatic retry, and that leaves two possibilities I can think of-

1) the client application code, having had the connection close gracefully before it could get any reply to any request may have decided to try connecting again. if the client is running on HP-UX, you can take a tusc system call trace to see that.

2) there were actually more than 9 pending connections so when you closed the 9th there was a 10th sitting there.

if you call shutdown() eventually you still must call close() or you will run out of file descriptors.

if you only want to handle 8 connections at a time, why not simply stop calling accept() (or even selecting on the listen socket) and let the connections remain in the listen queue?

[Suresh R]

Muthu, Jones,

My algorithm is something like below

initialize the listen socket
while (1) {
select on the listen socket for 100msec
if (activity) {
accept only if u have a free slot,
else reject the connect (by accept
and close)
}
select on each of the 'fd' of already accepted connections (if some connection is freed, then update the free list)
if (activity) then process each of fd for about 500msec or so
}

so, you would see that i am re-cycling the freed connections in my while loop.

Muthu's soln: i shud'nt be re-initializing a socket everytime only to 'reject' a connection, unless there is no other way, ofcourse.

Jones soln: Same answer for the shutdown part. Also, I am sure its not some 9th connection, 'coz I have only one client requesting connection after an 8th. But for the qn 'why not simply let the conn req q up in the listen socket' -- the only concern is that i am notifying the client that i dont have to accept its connection.

[rick jones]

You should combine your select() calls into one for both the active FDs and the listen FD. If I'm interpreting your pseudocode correctly, when you have fewer than 8 connections accepted, but no pending connections to accept, processing on those accepted will be delayed by the timeout on the select() on the listen endpoint.

Apart from that, I'm not shure what to suggest apart from tripplechecking the client code and what it does on connection close.