The initiator and acceptor may specify the maximum message size supported in the MaxMessageSize(383) field in the Logon(35=A) message.
Either peer may terminate a FIX connection due to inability to process the maximum message size specified by the other peer by sending a Logout(35=5) message.
The peer terminating the FIX connection should specify the reason in the Text(58) field of the Logout(35=5) message by setting it to “MaxMessageSize(383)=InboundValue exceeds maximum message size of maximum message size”.
Questions:
Does it mean that the peer terminating the FIX connection is unable to limit its outgoing messages with a specified size?
What is a “maximum message size” that the InboundValue exceeds?
It looks like values of MaxMessageSize for both peers must be the same to avoid such conflicts; is it correct?
Our previous understanding implied:
MaxMessageSize is a limit for inbound messages
each peer could have its own MaxMessageSize and they weren’t correlated
peer-initiator uses the tag MaxMessageSize to inform peer-acceptor about the inbound message size limit on the initiator side,
peer-acceptor uses the tag MaxMessageSize to inform peer-initiator about the inbound message size limit on the acceptor side,
The Logon(35=A) message allows to communicate the maximum message size one is able to take in from the counterparty. It does not specify one’s own maximum message size. The counterparty getting information about the maximum message size must assess whether that size is a problem.
If the value is a problem then a Logout(35=5) message is the right answer. InboundValue exceeds simply stands for the size value received and assessed as too large. The Text(58) fields is then to be used to a) tell the other side that the value is too high and b) tell the other side what one’s own maximum is. Note that in this case the information is in Text(58).
If the value is not a problem then a Logon(35=A) message is the right answer (if authentication is also ok). It is then the initiators turn to take in MaxMessageSize(383) from the acceptor and to validate if it is a problem.
MaxMessageSize for both peers does not have to be the same. Your previous understanding sounds fine with the exception of “no reason to reject each other limit”. A peer has to reject the Logon request from the counterparty if the peer is unable to guarantee that he will not send messages to that counterparty exceeding the maximum message size (=limit) provided by that counterparty.
As I understand, the peer has to send a Logout if it’s not possible to guarantee the not exceeding the MaxMessageSize received from the other peer.
Then the MaxMessageSize(383)= InboundValue exceeding the own maximum outbound message size of maximum message size looks ok.
If so, then the phrase
“MaxMessageSize(383)= InboundValue exceeds maximum message size of maximum message size”
should look like
“maximum outbound message size exceeds maximum message size of MaxMessageSize(383)= InboundValue”
or to avoid misunderstanding
"Can’t guarantee not exceeding the maximum message size of MaxMessageSize(383)= InboundValue”.
“A sends a Logon(35=A) message to B with MaxMessageSize(383)=123”
means that A is able to process an inbound message up to 123 bytes long
“B is unable to process anything longer than 100 bytes”
means that B is able to send an outbound message up to 100 bytes long that does not exceed the limit declared by A (123b).
“B responds with a Logout(35=5) message and Text(58)=“MaxMessageSize(383)=123 exceeds maximum message size of 100””
looks strange: is it a problem for A to process the 100b message which is less than the declared limit 123b?
“A may be able to adjust and could send another Logon(35=A) message to B with MaxMessageSize(383)=100.”
I do not understand why A has to adjust anything: its limit 123b covers the 100b message sent by B.
Hmmm…your first interpretation is different from mine and I now believe you are correct. It shows that you had good reason to start this thread. My understanding was that A uses this message to tell B what the maximum message size is that A will be sending to B and B would use Logout to tell A that is unable to process that size.
This paragraph in the spec is the issue I believe because saying to the peer “inability to process” implies that one gets a message that is too long. It does not imply the inability to keep the length of sent messages below the value received from the peer. I will take this issue to the FIX Global Technical Committee for clarification.
Based upon this discussion here is a proposed editorial change: The maximum message length in octets that the FIX session processor is able to receive may be specified in the MaxMessageSize(383) field in the Logon(35=A) message. The MaxMessageSize(383) value may be used to control message fragmentation at the application layer for those applications messages that support fragmentation. A FIX session processor may terminate a FIX session if the MaxMessageSize(383) specified by the peer is not sufficient by sending a Logout(35=5) message setting the Text(58) field to “MaxMessageSize(383) =InboundValue< required message size M” (where M is the required maximum message size.
It should mean that some minimum message size exists for outgoing messages, right?
If so, then the last phrase should be reworded as “(where M is the required minimum message size)”.
No, the value is only about an upper limit to message sizes that can be processed by the side that uses MaxMessageSize(383) in its Logon(35=A) message. Maybe your misunderstanding lies with the term “InboundValue”. That term is used from the perspective of the user that receives a Logon(35=A) message with MaxMessageSize(383) being used and only refers to the Logon(35=A) message (which is inbound from his perspective).
The term “required” is from the same perspective to indicate that he would like to send larger messages but since his peer sent him a lower value, decides to send a Logout(35=5) message. I believe what you are trying to express is that the user says “I will only accept a Logon request if the maximum message size you can process is at least M bytes or more”. However, using the term “minimum” here may lead to confusion rather than clarify the issue.