CODEWITHSUNDEEP
pythonsocketstcpgame-maker
SuperDisk
SuperDisk

Reputation: 2840

Python server and Game Client: Message overload?

I'm writing a game server in Python and a game client in Game Maker with the Faucet Networking plugin (though that shouldn't matter). The client sends an UPDATEXY message to the server each time the player moves, and there is a message chatting thing in the client. With 2 clients connected to the server, it seems that the client gets overloaded with messages (further into the run time, chat messages appear slower and the player lags behind where the actual other player is). I believe this is because the client cannot process the messages at the rate they are flowing in, so I implemented a feature in the client where it would just dump all messages in the receive buffer, and ignore them. This seemed to work, but the player would jerk around violently. Is there any sort of 'clean fix' to this problem, or is it a fundamental thing that I have done wrong since the start?

By the way, the protocol I am using is TCP. Is this a problem with TCP itself or am I just using it wrong? Would switching to UDP help?

Thanks.

EDIT: Code was requested so here you go for the server:

def sendmsg(msgtype, msg, conn, args=None):
    if msgtype == MSG_PLAYER_ASSIGN_ID:
        dataload = struct.pack('!hhh', MSG_STARTBYTE, msgtype, msg)
        conn.send(dataload)

    elif msgtype == MSG_PLAYER_UPDATEXY: #This will only ever be broadcasted
        #print("Sending xy from " + str(args['pid']))
        dataload = struct.pack('!hhhhh', MSG_STARTBYTE, msgtype, args['pid'], msg[0], msg[1])
        conn.send(dataload)

    elif msgtype == MSG_ASKFORLIST:
        players = msg
        for player in players:
            if args['pid'] != player.pid and player.dead == False:
                dataload = struct.pack('!hhhh' + str(len(str(player.name))) + "s", MSG_STARTBYTE, MSG_PLAYERENTRY, player.pid, len(str(player.name)), player.name.encode())
                conn.send(dataload)
                loginfo("Sent a player")

^That's just a few packets, there are more, but they are all pretty much like those

Here you go for the client:

if msgtype == MSG_PLAYER_UPDATEXY
{
if tcp_receive(serversocket, 6){
pidtoupdate = read_short(serversocket)
//show_message(string(pidtoupdate))
if objNewNetProcessor.pid != pidtoupdate
{
xtoupdate = read_short(serversocket)
ytoupdate = read_short(serversocket)
playertoupdate = ds_map_find_value(global.players, string(pidtoupdate))
if playertoupdate != objChar
{
playertoupdate.y = ytoupdate
playertoupdate.x = xtoupdate}
}}}

if msgtype == MSG_CHAT
{
if tcp_receive(serversocket, 4){
fromperson = read_short(objNewNetProcessor.serversocket)
strlen = read_short(objNewNetProcessor.serversocket)
tcp_receive(objNewNetProcessor.serversocket, strlen)
chatmsg = read_string(objNewNetProcessor.serversocket, strlen)
display_chat(fromperson, chatmsg)
}}

^Sorry that's a total messtastic, it's just temporary code for now. It too is just a few packets, it handles more below that code, though they all look similar to those.

Upvotes: 1

Views: 859

Answers (2)

Medo42
Medo42

Reputation: 3821

Generally this should work fine, and I doubt this is a problem with high CPU load - 60 updates per second is quite a lot, but with only two clients connected there should not be that much traffic to process. For comparison, Gang Garrison 2 uses only 30 updates per second, but with a decent PC it can handle 20 players on a server just fine. Check the client and server CPU load in task manager to be on the safe side, but I don't expect that to be the problem.

If clearing the "backlog" on the clients makes them catch up, this is probably not a problem with the network speed or the server either, but it might still be valuable to log the traffic on a client with Wireshark to see if everything looks as expected (e.g. packets are sent and received at the expected rates and are evenly timed).

Since there seems to be a backlog building up on the clients: Do the clients try to consume as many messages as possible each step, or only the messages for one server step? If you only process one server step per client step, any connection hiccups that inevitably happen will cause you to permanently lag behind, which seems to be consistent with what you describe.

Russell Borogove gave you a good pointer as well, definitely make sure that Nagle's algorithm is disabled (=tcp_nodelay is enabled) on each game-related socket on the server. Faucet does this by default.

Upvotes: 1

Russell Borogove
Russell Borogove

Reputation: 19057

TCP is normally configured to wait up to about 200ms before sending anything if a good-sized chunk of data is not yet ready to be sent (on the order of 100 to 1000 bytes). This is called the Nagle algorithm. With clients trying to send updates at 60fps (~16ms period), this means you'll be bursting a lot of obsolete data.

It is possible to turn off Nagle buffering, but UDP is more appropriate for things like constant position updates in a real-time game.

That said, I would expect a Python server on a reasonably fast machine to be able to keep up with 2 clients' worth of updates, so there may be something else going on.

Upvotes: 1

Related Questions