Refusing TCP connections - ServerSocket

[Steve Sobol]

I want to create a ServerSocket.

I want it to accept one connection.

If another connection request comes in, I want it to be refused, not queued.
Even if I set backlog to 1, on the OS I'm testing on (Linux) I'm able to
queue up a bunch more connections (5 or 6).

I know the actual backlog size is OS dependent even if I explicitly set it
in the ServerSocket constructor.

So, how do I refuse all subsequent connections after I accept that first one?

 

[Knute Johnson]

I want to create a ServerSocket.

I want it to accept one connection.

If another connection request comes in, I want it to be refused, not queued.
Even if I set backlog to 1, on the OS I'm testing on (Linux) I'm able to
queue up a bunch more connections (5 or 6).

I know the actual backlog size is OS dependent even if I explicitly set it
in the ServerSocket constructor.

So, how do I refuse all subsequent connections after I accept that first one?

You could close the ServerSocket until you were ready to accept
connections again.

 

[Steve Sobol]

I asked

Knute Johnson suggested

You could close the ServerSocket until you were ready to accept
connections again.

And that works wonderfully. Thanks!

 

[Curt Welch]

You could close the ServerSocket until you were ready to accept
connections again.

If you wanted to accept multiple connection but not until you you were done
with the first one, the other option is to accept all connections and just
close the connection after accepting it. It depends on the protocol
whether that would make sense or whether that would get you in trouble
(like if that just made the clients try to connect again). But if you want
to accept a single connection, and no more, then Knute is correct, just
close the ServerConnection after you accept the first connection. Closing
the ServerSocket will not effect the socket you just accepted. You can
still go ahead and use it for whatever was needed.

 

[Steve Sobol]

If you wanted to accept multiple connection but not until you you were done
with the first one,

I like Knute's option, though, because it doesn't require me to accept
connections. In my opinion, it's somewhat cleaner than accepting-then-dropping.

So if I want to allow X connections at a time, I maintain a counter and
call ServerSocket.close() when I reach X.

 

[Curt Welch]

I like Knute's option, though, because it doesn't require me to accept
connections. In my opinion, it's somewhat cleaner than
accepting-then-dropping.

So if I want to allow X connections at a time, I maintain a counter and
call ServerSocket.close() when I reach X.

It all depends on the protocol and the application really. If it's normal
for the server to accept multiple connections but be limited by the number
it can handle, the more typical way to do it is accept the connection, and
report an error back to the client using a protocol specific message over
the connection and then close. This way, the client can tell the
difference between an overloaded server and a down server. Servers
normally, once started, never stop accepting connections. It's very odd
for a long lived server to stop listening for new connections.

It's normally not allowed for two servers to listen on the same port. If
one server is already running, the second will get an error saying it can't
bind to the port. So keeping the socket open is a simple way of preventing
two servers from running at the same time on the same port. If you open
and close the port as you are ready to accept connections, you could get
the possibility that multiple servers are running, and fighting to see who
can use the port next.

On the other hand, if you are writing a special application which is
designed to accept only a single connection on a temporary port, then the
way you are doing it wouldn't be that odd.

It all depends on the application.

 

[Martin Gregorie]

I want to create a ServerSocket.

I want it to accept one connection.

If another connection request comes in, I want it to be refused, not queued.
Even if I set backlog to 1, on the OS I'm testing on (Linux) I'm able to
queue up a bunch more connections (5 or 6).

Are you limiting connections because your server instance can't handle
multiple connections, but running several servers would be OK or because
you only want a single connection per host?

Either way you should consider writing your server to run under the
control of xinetd if its intended to run on a *NIX type system. The
benefits are that your server doesn't need to handle sockets (xinetd
does that for it) and your service definition says how many copies
xinetd is allowed to start.