Title: Functions of client-server handling in multiplayer-games PART II
Question: About different service providers and message handling
Answer:
Release 2 last update: [06.05.2000]
----------------------------------------------------------
Functions of client-server handling in multiplayer-games
----------------------------------------------------------
---------------------------------------------
PART II: Performance of service providers
---------------------------------------------
- Personal comments
Maybe my english is bad, thats because I am german. I am using
the information described in this article in my current game
called FinalFighter which I am developing. Check out
www.finalfighter.com. Feel free to message me about this article
and/or my project.
- Status
This memo describes the functions of a client-server oriented
communication in computer games. The technology described in
this document is independent from any programming language.
It's only an example how to build such an interface. This
article is the successor of PART I, check it, before reading this
one.
- Introduction
In the first part of this memo, we discussed general things
about different server types and their communication. In this
part of the memo we will get to know somthing about different
service providers and how to prevent lagging in your game.
- Service providers
Before you can send something over a network you must choose
a service provider like TCP/IP, IPX or any other protocol (modem
or serial-port connection). The most known service provider
today - also used for the internet and local area networks in
enterprises - is TCP/IP. Another protocol which came from
Netware is IPX, it's only used in local area networks.
Modem and serial connections are used to connect only two PC's
over a telephone line or by the PC's serial port. These two
connection methods are outdated and uninteresting for our
game programming project, so we won't go into further detail.
The DirectPlay-protocol included in the DirectX runtime from
Microsoft encapsulates all this service providers we already
mentioned, so you can easily include this technologies in your
game - when you programming a windows-game - without having
any trouble with different protocols or hardware.
- About TCP/IP
TCP/IP is a service provider which is used all over the internet
and also in all kinds of local area networks. Every machine
using this protocol can have one or more IP-addresses which
identify the computer globally. This addresses can only be
modifyed by hardware-drivers and the operating system, not by
your game. So it's not advisable to use the IP as global PlayerID
in your game, because the client can run multiple instances
of the game, or he can use one shared telephone line - by two
or more computers - which causes that all machines using this
connection had one and the same IP. The TCP/IP protocol uses
ports through which the messages are transmitted to prevent mixing
them up with messages from other applications. You can use
any port between 1 and 65535 for your application. All client
who wants to connect to the server must know the servers port to
connect to. All messages send through this network can be send
in two ways: guaranteed and unguaranteed. TCP/IP sends guaranteed
with the help of TCP included in this protocol. Guaranteed
messages are used to send important messages like game states or
something else. This type of message-sending takes more time and
the packets send are bigger than unguaranteed ones.
Unguaranteed messages are send with the UDP-technology, they
can be used to post less important things like the player's
position or something like this.
- Network performance and prevent lagging
The largest problem when writing a network computer game is to
minimize the amount of data sent, to prevent player-lagging
in your game. Before writing the network message handling in
your game you should consider different bandwidths which the
end-user could use. Your game must be able to work less-lagging
when for example four players playing on the average with a
6kb/sec connection (ISDN or 56K-Modem) and someone with a 2kb/s
(28K-Modem) joins the game. This may cause that the 2kb-player
unintentionally manipulates the gameplay because other players
can't recognize him correctly because of the lag. There are not
many solutions for this problem, the only good one is to keep
the amount of data sent low. Another (bad) solution is to kick
the lagging player or to test the performace of bandwidths
for every player before the game starts. Another important
thing we should also know is that the gamespeed isn't only
depending on the bandwidth of the network, but also on the
connections of the internet providers in different countries.
The IRC network for example, has different general servers
(general server: see PART I) which are connected together. Each
server only allows a connection from a user who lives in a
specific sector in the world. E.g: Only users living in europe
can connect to a server in Paris. You can resolve the
country where an user lives by the hostname (to get hostname -
resolve the IP). But here we won't go into further detail.
We should remember that all these problems refer to internet
connections. We don't have these problems in local area networks
because the LANs always have a bandwidth which is large enough
to ensure a less-lagging gameplay.
- About asynchronous sending
It can be an good advantage, sending messages asynchronously
because this prevents unnecessary blocking in your game.
When using synchronous message sending, a thread which sends
the message is called and it only ends, when the message was
successfully or unsuccessfully transmitted to the receiver. In
the time where the thread is active, no other messages can be
send. This is very unsuitably for your multiplayer-game, because
this blocks the complete game when it takes longer than normally
to transmit a message. Windows' Winsocks from version 2.0
or DirectPlay support asynchronous message sending with TCP/IP,
so it's recommended to use it. When you are unable to use it
(e.g. the service provider doesn't support it) so you can
write your own asynchronous-message-sending method by using
a message-queue with multiple threads. These queues are often
limited to 16 messages. And you should always use the complete
bandwidth aviable. When you find that there is place for more
messages in the message-queue, than you can complete it by
sending more messages. But this must be automatically controlled
by the game itself. Example: we have a game with two players
currently playing using the complete bandwidth of our network.
When someone joins the game, the sending of messages should be
minimized, so that the game can be continued without lagging.
---------------------------------------------------------------
End of PART II