Maximum number of simultaneous connections

[Tomaž Kunaver]

Hi,

I was wondering, how can I set the maximum number of allowed connections for my server? I'm using a TCP server only.

[Joachim Durchholz]

The most likely cause is a limit imposed by the operating system.
You should be ablet to verify that by inspecting the exception trace.

[Tomaž Kunaver]

Actually, I'm not getting any exceptions. What I want to do though is to LIMIT my connections to like 100, since my game server does a lot of work with each client and I don't want more than 100 clients connecting, or else my server would become too slow.

[Joachim Durchholz]

Am 31.12.2016 um 12:04 schrieb Tomaž Kunaver:
> Actually, I'm not getting any exceptions.

You should.

I don't know whether that's the case for your code, but many people do
stuff like
try {
// do something that may throw exceptions
} catch (Exception ex) {
// ignore
}

which silently swallows any exceptions.
Instead, the code should be
try {
// do something that may throw exceptions
} catch (Exception ex) {
// this if the caller shouldn't continue:
throw new RuntimeException(ex);
// if the error should be output instead
// (for some suitable preinitialized logger accessible as 'log':
log.error("some text that explains what operation failed", ex);
}

Servers definitely need logging BTW. One cannot debug servers easily
(clients would run into timeouts etc.), and without a debugger, the best
replacement is a good log.

> What I want to do though is to
> LIMIT my connections to like 100, since my game server does a lot of
> work with each client and I don't want more than 100 clients connecting,
> or else my server would become too slow.

On a Linux server, you can enforce a limit on the number of open file
handles, which includes TCP connections. Since database connections and
open files count in as well, you would need to measure how many files
are actually open and discout for that, plus be ready for surprises, so
it's more like a stopgap solution.

If you want to play safe and limit the number of game clients
connecting, you'd better do that at the caller level, i.e. the piece of
code that keeps track of connected game clients.
Otherwise you might get the same problem as with file handles: Some
library you're using and you aren't even aware that it uses Kryonet
might create Kryonet connection that suddenly start draining your game
client connection limit.

[Tomaž Kunaver]

Yeah, that's what I did - I limited the number of clients on application level. That is, when new client connects, I simply disconnect him immediately if there are too many clients logged in already.

However, I have another question regarding this problem. My code that does client limiting is as follows:

server.addListener(new Listener() {

public void connected(Connection c) {

if (users.size() >= MAX_PLAYERS) {

c.sendTCP(new Commands.ServerIsFull());

c.close();

}

}

}

My question is this: will the client always receive ServerIsFull command? I mean immediately after sending the command I disconnect him, so I'm wondering how the dropped packet are handled etc.

[Joachim Durchholz]

Am 31.12.2016 um 13:27 schrieb Tomaž Kunaver:
> However, I have another question regarding this problem. My code that
> does client limiting is as follows:
>
> server.addListener(new Listener() {
> public void connected(Connection c) {
> if (users.size() >= MAX_PLAYERS) {
> c.sendTCP(new Commands.ServerIsFull());
> c.close();
> }
> }
> }
>
> My question is this: will the client always receive ServerIsFull
> command?
> I mean immediately after sending the command I disconnect him,
> so I'm wondering how the dropped packet are handled etc.

I'd expect TCP to close the low-level machinery only after the last
packet has been sent and acknowledged by the receiver.
It's a property that's really easy to destroy (just buffer the data but
not the close() calls), so I wouldn't want to give any guarantees.
Also, I wouldn't want to critically rely on that. Too many failure modes
in networking. I'd build the clients so that they time out pretty quickly.

More importantly: Give the users feedback. Tell them how full each
server is, whether it responded at all. They will learn to select a free
server.
I.e. the ServerIsFull command should carry some statistics.