Hi,
I'm currently co-developing a game (draughts, see www.damserver.nl) server that
utilises Tomcat for message passing and relaying, which is in a testing phase right
now. During development of the server (on a fast network) we encountered no big
problems with Tomcat, but since testing has intensified somewhat (especially by
testers on slow modem connections) it sometimes seems like Tomcat drops connections to
clients randomly every now and then.
In short, the server works a bit like a chat server, with the exception that not only
chat messages are relayed by it, but also moves, connection state information, user
actions etc. The server keeps no internal state about board setups etc. (this is all
handled by the clients), but only which users are logged in, where these users are at
any moment (portal, room, table screen), and what games are being played by which
users. Clients communicate with the servlet engine through only 1 servlet (this is
because the servlet specs advise against sharing state information between servlets),
which acts like a 'proxy' between the network and the server logic. We don't use the
HTTP protocol (ie: we dont use HttpServlet but GenericServlet), but we do use the HTTP
port.
Messages are encoded and sent (by 'requesting' the game server servlet) as raw data to
the servlet engine (both server and client use DataInputStream's and DataOutputStreams
to read/write data). The server then decodes the data, relays the message to clients
if necessary, passes new messages to clients if the received message demands it and
returns a response to the client that sent the message. This response also contains
only raw data, which is usually (but not always) no more than an acknowledgement.
Clients get their messages by polling the game server 2 times/second (they do this by
sending a special message to the game server servlet, which in turn writes back all of
the clients' messages as a response to the 'request' containing the message). The
clients need to poll because we can only use the request-response paradigm, since the
server should be accessible from behind a firewall. The server expects connected
clients to fetch their messages at least once every 2 minut
es, and checks this by dropping a 'ping' message in all its client message queues,
and verifying that it gets consumed within 2 minutes.
The problems we encounter seem to surface only when a client connects using a 'slow'
connection, especially with modem connections but maybe also with cable connections
(which have little upstream bandwith). The symptoms are that after some time playing a
game a client does not receive messages anymore. The game server keeps working fine,
and the client also goes on happily. It just does not receive any more messages,
although the server definitely sends them. Ofcourse this probably looks like bug in
our code, but we do not think this is the case, since we cannot reproduce the bug on a
fast network. It seems as if the Tomcat server sometimes randomly kills a request
(especially under heavy load) without sending a response. The client thread that polls
the server still expects this response but it does not get it, so it blocks, and no
new requests for messages are made. After some time the game server detects that the
client did not consume its messages, and logs out the user.
As a side note I would like to mention the fact that we had to increase the maximum
number of simultaneous threads per servlet to get acceptable performance if more than
8 people were logged in at the same time,
Now for the question this post is all about: is it possible that tomcat sometimes
randomly kills a request, does not process a request or queues a request indefinitely,
thereby blocking all further communication with a client? Is this possible because the
server communicates with the clients using only raw data and
InputStreams/OutputStreams? And: is it a good idea to develop a game server like the
one described here using Tomcat, considering the fact that tomcats main purpose is to
act as web application server using a strict request-response paradigm. Our project
development team suspects that tomcat was never meant for this type of applications
(that produce very small, but very frequent requests, and are really
connection-sensitive), and that it is not safe to assume that every request made by a
client always yields a proper response.
Don't get me wrong: I do *not* think there's something wrong with tomcat! As a matter
of fact I have really good experiences with it using it for web applications!!
Kind Regards,
Wouter Bijlsma,
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
