You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should use the _negotiate_integer_value method in _tune_heartbeat_timeout
Section 2.3.3 from the AMQP 0.9.1 protocol spec reads:
The AMQP client and server negotiate the protocol. This means that when the client connects, the server proposes certain options that the client can accept, or modify. When both peers agree on the outcome, the connection goes ahead. Negotiation is a useful technique because it lets us assert assumptions and preconditions.
In AMQP, we negotiate a number of specific aspects of the protocol:
The actual protocol and version. The server MAY host multiple protocols on the same port.
Encryption arguments and the authentication of both parties. This is part of the functional layer,
explained previously.
Maximum frame size, number of channels, and other operational limits.
Agreed limits MAY enable both parties to pre-allocate key buffers, avoiding deadlocks. Every incoming frame either obeys the agreed limits, and so is "safe", or exceeds them, in which case the other party IS faulty and MUST be disconnected. This is very much in keeping with the “it either works properly or it doesn't work at all” philosophy of AMQP.
Both peers negotiate the limits to the lowest agreed value as follows:
The server MUST tell the client what limits it proposes.
The client responds and MAY reduce those limits for its connection
The RabbitMQ Java client uses these functions to determine the heartbeat value
We should use the
_negotiate_integer_value
method in_tune_heartbeat_timeout
Section 2.3.3 from the AMQP 0.9.1 protocol spec reads:
The AMQP client and server negotiate the protocol. This means that when the client connects, the server proposes certain options that the client can accept, or modify. When both peers agree on the outcome, the connection goes ahead. Negotiation is a useful technique because it lets us assert assumptions and preconditions.
In AMQP, we negotiate a number of specific aspects of the protocol:
explained previously.
Agreed limits MAY enable both parties to pre-allocate key buffers, avoiding deadlocks. Every incoming frame either obeys the agreed limits, and so is "safe", or exceeds them, in which case the other party IS faulty and MUST be disconnected. This is very much in keeping with the “it either works properly or it doesn't work at all” philosophy of AMQP.
Both peers negotiate the limits to the lowest agreed value as follows:
References:
The text was updated successfully, but these errors were encountered: