This repository was archived by the owner on Oct 4, 2022. It is now read-only.
Carrier can't send large messages with data compression enabled#542
Open
m9co wants to merge 1 commit intoaws:masterfrom
Open
Carrier can't send large messages with data compression enabled#542m9co wants to merge 1 commit intoaws:masterfrom
m9co wants to merge 1 commit intoaws:masterfrom
Conversation
When sending data, that exceed maximum message size, Carrier will split in into several smaller ones. Maximum message data size is defined by variable m_maxMsgDataSizeBytes, which is calculated as following:
m_maxMsgDataSizeBytes = m_maxDataGramSizeBytes - GetDataGramHeaderSize() - GetMaxMessageHeaderSize();
When data compression is enabled, in addition to datagram and message headers, carrier adds additional header with compression hint flags (added in CarrierThread::SendDatagram).
Compression header is not accounted in m_maxMsgDataSizeBytes and resulting split messages won't be sent due to following code from CarrierThread::GenerateOutgoingDataGram:
//If this Message can fit into the remaining Datagram buffer space
if ((msg.m_dataSize + GetMessageHeaderSize(msg, isWriteMessageSequenceId, isWriteReliableMessageSequenceId, isWriteChannel))
> (maxDatagramSize - writeBuffer.Size()))
{
break; // we can't add this message
}
Moreover, these messages will remain in send queue and completely block the network.
Issue happens only for messages, sent through custom network channels and not for regular game synchronization performed by replica manager. Replica manager uses channel 0, which is not included in message header, freeing up a necessary byte.
|
Hello @m9co! We've integrated your pull request and wanted to let you know that you should be able to see your changes in our next version of the Lumberyard engine. Thank you kindly for contributing to Lumberyard! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When sending data, that exceed maximum message size, Carrier will split in into several smaller ones. Maximum message data size is defined by variable m_maxMsgDataSizeBytes, which is calculated as following:
When data compression is enabled, in addition to datagram and message headers, carrier adds additional header with compression hint flags (added in CarrierThread::SendDatagram).
Compression header is not accounted in m_maxMsgDataSizeBytes and resulting split messages won't be sent due to following code from CarrierThread::GenerateOutgoingDataGram:
Moreover, these messages will remain in send queue and completely block the network.
Issue happens only for messages, sent through custom network channels and not for regular game synchronization performed by replica manager. Replica manager uses channel 0, which is not included in message header, freeing up a necessary byte.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.