Uploaded image for project: 'Qpid Dispatch'
  1. Qpid Dispatch
  2. DISPATCH-525

What are proper names and units for protocol configuration settings?

    XMLWordPrintableJSON

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 0.7.0
    • Fix Version/s: 1.0.0
    • Component/s: Management Agent
    • Labels:
      None

      Description

      Several settings are available in configuration objects that are used in AMQP negotiations with clients. Some of them are confusing as they exist now and could be redefined to make their understanding and usage easier for end users. The same settings are defined for Router Listener and Connector and for Policy Vhost objects.

      Setting Units Range
      maxFrameSize octets uint
      maxSessions sessions uint16
      maxSessionWindow octets uint
      maxMessageSize not implemented octets uint
      linkCapacity messages integer

      These settings have to work in cooperation with the proton engine interface.

      maxFrameSize

      This setting is straightforward. The range is 0..ULONG_MAX.

      Using octets is fine. This value must be 512 or larger per AMQP spec.

      Proposal

      Leave this setting unchanged.

      maxSessions

      This setting is in units of 'sessions'. The acceptable values are in the range 1..65536.

      The number given in the configuration is one larger than the value used by AMQP and proton. In AMQP the channel-max value of an Open is the largest channel number that can be used. So a channel-max of 0 allows one session, and a value of 1 allows two sessions, and so on.

      I prefer to have the spec values be equal to the number of sessions allowed.

      • Dispatch code subtracts one from the specified value and puts it into proton channel-max.
      • A value of zero in the spec can be disallowed or it can mean some default value.

      Proposal

      Leave this setting unchanged.

      maxSessionWindow

      This setting is in octets. The range is 0..ULONG_MAX with a minimum of max-frame-size octets.

      This setting is slightly confusing as the specification is in octets. Then that value of octets is passed to proton in pn_session_set_incoming_capacity. Proton divides the incoming_capacity by the max-frame-size and uses the result in a Begin incoming-window. The incoming-window then is measured in transfer frames. For example:

      • maxFrameSize = 65,536.
      • maxSessionWindow = 1,000,000.

      Dividing (1000000 / 65536) = 15 frames. The 15 is used in the Begin/incoming-window field during negotiation with the peer.

      A user expecting to have about a megabyte of buffering on the session might be surprised to find all the buffering consumed by 15 100-byte transfer frames.

      Proposal

      • Rename this setting to maxSessionFrames.
      • Change this setting's units of 'transfer frame'. Then the value sent to proton in incoming_capacity would be calculated by (maxSessionFrames * maxFrameSize). The value of maxSessionFrames would then appear in the Begin/incoming-window field.

      maxMessageSize

      This setting is in octets. The range is 0..ULONG_MAX.

      This setting is TBD. No interface in proton engine is available to change it. If this value is zero or, more typically, not set then there is no maximum message size.

      Proposal

      Leave this setting unchanged.

      linkCapacity

      This setting is in transfer frames. The range is 0..LONG_MAX.

      This setting defines how much credit is issued on links created on a connection. It specifies how many transfers can be in-flight concurrently for each link.

      This setting is for Listener and Connector objects only. It is not defined for Policy Vhost objects.

      Proposal

      • Leave the units and current meaning of this setting unchanged.
      • Add this value to the Policy Vhost settings so that it may be overridden on a Vhost Usergroup basis.

        Attachments

          Activity

            People

            • Assignee:
              chug Charles E. Rolke
              Reporter:
              chug Charles E. Rolke
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: