Network messaging on WZ2100

[Cyp]

I've been trying to understand, in the NETSend function, when the host is going to redirect certain GAME messages. The thing is, the type of messages i catch in this function are always NET messages: NET_SHARE_GAME_QUEUE or NET_SEND_TO_PLAYER, never GAME specific messages, even do i know other players receive them.

Does anyone know what i'm talking about? I'm a bit lost here.

Thanks

All the GAME_* messages are smuggled on board the NET_SHARE_GAME_QUEUE messages. The GAME_* messages are then stored in game queues ready to be processed at the same time in the same order on all clients.

[cajadas]

Great. That's just what i wanted to know. Thanks Cyp.

By the way. Is there a way for me to know, in the NETsend function, what's the type of the GAME message inside the NET_SHARE_GAME_QUEUE message? And also, is there a NET_SHARE_GAME_QUEUE message for each GAME message to be sent or a single NET_SHARE_GAME_QUEUE message can support more than one GAME message?

[Cyp]

Search for NET_SHARE_GAME_QUEUE in lib/netplay/nettypes.cpp, there it posts all pending GAME_ messages in a single NET_SHARE_GAME_QUEUE.

It might be simpler to see the GAME_ message types at that point in the code, rather than decoding the NET_SHARE_GAME_QUEUE from the NETsend function itself.

[cajadas]

Ok, now i'm on the NETflushGameQueues() function and after checking if are there any number of messages to be sent i've written something like these:

Code: Select all

NetMessage message = queue->getMessageForNet();
debug(LOG_WZ, "Message_type: %s", message.type);

to get the type of the message to be transmitted, but i keep getting segfault. Obviously i'm not access memory correctly. What would be the write way to do it? (I'm felling noobish right now).

[vexed]

Ok, now i'm on the NETflushGameQueues() function and after checking if are there any number of messages to be sent i've written something like these:

Code: Select all

NetMessage message = queue->getMessageForNet();
debug(LOG_WZ, "Message_type: %s", message.type);

to get the type of the message to be transmitted, but i keep getting segfault. Obviously i'm not access memory correctly. What would be the write way to do it? (I'm felling noobish right now).

Um, message.type isn't a string, it is a uint8_t.

[Cyp]

messageTypeToString(message.type) is a string, though.

Code: Select all

NetMessage message = queue->getMessageForNet();
debug(LOG_WZ, "Message_type: %s", messageTypeToString(message.type));

[cajadas]

Ok, now i can read the message type before encoding the NET_SHARE_GAME_QUEUE, however, when i use the code

Code: Select all

NetMessage message = queue->getMessageForNet();
debug(LOG_WZ, "Message_type: %s", messageTypeToString(message.type));

NETbeginEncode(NETbroadcastQueue(), NET_SHARE_GAME_QUEUE);
	NETuint8_t(&player);
	NETuint32_t(&num);
	for (uint32_t n = 0; n < num; ++n)
	{
		queueAuto(const_cast<NetMessage &>(message));  
                queue->popMessageForNet();
	}
NETend();

I get some unusual debugging output that doesn't appear using the original. Something like this:

Code: Select all

error   |05:04:36: [checkDebugSync] Inconsistent sync debug at gameTime 10502. My version has 192 lines, CRC = 0x65A152BE.
error   |05:04:36: [gameTimeUpdate] Synch error, gameTimes were: {     10502,      10502,      10502,      10502}
error   |05:04:36: [gameTimeUpdate] Synch error, CRCs were:      {0x9AAA543E, 0x65A152BE, 0x9AAA543E, 0x9AAA543E}
wz      |05:04:36: [NETflushGameQueues] Message_type: GAME_GAME_TIME
error   |05:04:36: [checkDebugSync] Inconsistent sync debug at gameTime 10602. My version has 116 lines, CRC = 0xC5AA316F.
error   |05:04:36: [gameTimeUpdate] Synch error, gameTimes were: {     10602,      10602,      10602,      10602}
error   |05:04:36: [gameTimeUpdate] Synch error, CRCs were:      {0x40D07C61, 0xC5AA316F, 0x40D07C61, 0x40D07C61}

Does anyone know why does this happen?

Thanks.

[Cyp]

In the above code, it looks as if you save the first message to be sent, and send that message num times, instead of sending all messages to be sent.

I think the "queue->getMessageForNet()" and the debug should be inside the loop.

[cajadas]

In the above code, it looks as if you save the first message to be sent, and send that message num times, instead of sending all messages to be sent.

I think the "queue->getMessageForNet()" and the debug should be inside the loop.

The problem is i want to block certain types of messages from being transmitted. If i put that code inside the loop, the num sent before i can identify the messages i want to block, will probably be different from the real number of sent messages.

From what i understand, the parameters of a message will always be read in the same order they were sent, and i can't change the order of the parameters because the num is needed to know when to stop reading new messages.

[Cyp]

Then, save all the messages in a std::list or something, remove the ones you don't want, then count how many are left and send them.

Blocking any kind of GAME_ messages will break synchronisation completely, so you will get the "Synch error" messages, and each client will be playing in its own separate (and rapidly diverging) universe.

If you want to block messages without completely breaking synchronisation, you could comment them out in recvMessage() in src/multiplay.cpp. If commenting out the GAME_DROIDINFO case there, the game should run normally, except that the tanks will ignore orders to move, for example.

[cajadas]

Blocking any kind of GAME_ messages will break synchronisation completely, so you will get the "Synch error" messages, and each client will be playing in its own separate (and rapidly diverging) universe

That's kind of what i'm trying to accomplish here. The algorithm i want to implement achieves consistency by only redirecting messages that are or soon will be necessary for the player to have all the information he needs to play the game correctly. As a result, GAME_DROIDINFO messages regarding positions that are outside the area of interest of player are not sent.

If you want to block messages without completely breaking synchronisation, you could comment them out in recvMessage() in src/multiplay.cpp. If commenting out the GAME_DROIDINFO case there, the game should run normally, except that the tanks will ignore orders to move, for example.

The thing is, with this algorithm i am trying to reduce the message traffic and bandwidth requirements. If i send the messages anyway and just ignore them in the receiver i don't accomplish anything.

If you ever have the chance to go to the #warzone2100-dev channel i'm usually on-line.

Thanks Cyp.

[Cyp]

Currently, I think how a tank moves in one end of the map can affect how a tank moves in the opposite end of the map. So I think it would be hard to find any messages that aren't immediately needed for the player to play the game correctly. Also, sending a single high-level order for 100 tanks to move to position X probably uses less bandwidth than later sending the exact positions of the 100 tanks, so only sending messages when needed could be less efficient, anyway.

There may still be some left-over synchronisation messages from the 2.3 network code that no longer need to be sent. GAME_DROIDDEST might be one, don't remember if it's still sent when a droid dies, but if so, it's a useless message since synchronised clients already calculate that the droid died (and send it themselves).

When a client sends a broadcast message, I think the host sends the message back to the client, which then ignores the returned message. Fixing that might save a bit of bandwidth.

[cajadas]

Sorry, i didn't mean to criticize the way the network communication is made. Actually, i think its great and the aggregation of messages to reduce bandwidth consumption is one of the factors i would implement myself. However, i'm implementing this algorithm as an academic project in which we intend to prove that bandwidth consumption can be reduced by only transferring updates referring to area of interest of the player. This area of interest is calculated by the algorithm.

In a first version of the project, we consider the central point of the area of interest is the map visible by the player, that's why i'm trying to block messages referring to areas not visible by the player. Although each player have enough game info to make immediate decisions, the host have all gamestate.

Do you think this is achievable? Why is this going to trigger "Sync error" and how can i avoid it?

[Per]

That is not going to work, unfortunately. The game is not client-server, it is peer-to-peer, and each peer has a full world simulation that has to be identical down to the last digit of every relevant number. This means that each peer has to have all the information. Once one peer is missing information, its simulation of the world will differ from that of another peer, and things will go out of sync. Shots will hit on one peer, while they miss on another, and so on.

In order to do what you are thinking about, you will need to create a server that has the full simulation and only shares the pieces of information that are relevant to clients. That would be a very different architecture, and an enormous amount of work.

[stiv]

In order to do what you are thinking about, you will need to create a server that has the full simulation and only shares the pieces of information that are relevant to clients. That would be a very different architecture, and an enormous amount of work.

But a very interesting experiment, nonetheless.