Net-AMQP

 view release on metacpan or  search on metacpan

lib/Net/AMQP/Protocol/v0_8.pm  view on Meta::CPAN

=item I<prefetch_count> (type: short)

Prefetch window in messages 

Specifies a prefetch window in terms of whole messages. This field may be used in combination with the prefetch-size field; a message will only be sent in advance if both prefetch windows (and those at the channel and connection level) allow it. 

=item I<consume_rate> (type: long)

Transfer rate in octets/second 

Specifies a desired transfer rate in octets per second. This is usually determined by the application that uses the streaming data. A value of zero means "no limit", i.e. as rapidly as possible. 

=item I<global> (type: bit)

Apply to entire connection 

By default the QoS settings apply to the current channel only. If this field is set, they are applied to the entire connection. 

=back

=head2 Net::AMQP::Protocol::Stream::QosOk

lib/Net/AMQP/Protocol/v0_8.pm  view on Meta::CPAN

</method>

</class>

  <class name="stream" handler="channel" index="80">
    <!--
======================================================
==       STREAMING
======================================================
-->
  work with streaming content

<doc>
  The stream class provides methods that support multimedia streaming.
  The stream class uses the following semantics: one message is one
  packet of data; delivery is unacknowleged and unreliable; the consumer
  can specify quality of service parameters that the server can try to
  adhere to; lower-priority messages may be discarded in favour of high
  priority messages.
</doc>

<doc name = "grammar">
    stream              = C:QOS S:QOS-OK
                        / C:CONSUME S:CONSUME-OK

lib/Net/AMQP/Protocol/v0_8.pm  view on Meta::CPAN

      field may be used in combination with the prefetch-size field;
      a message will only be sent in advance if both prefetch windows
      (and those at the channel and connection level) allow it.
    </doc>
  </field>

  <field name = "consume rate" type = "long">
    transfer rate in octets/second
    <doc>
      Specifies a desired transfer rate in octets per second. This is
      usually determined by the application that uses the streaming
      data.  A value of zero means "no limit", i.e. as rapidly as
      possible.
    </doc>
    <doc name = "rule">
      The server MAY ignore the prefetch values and consume rates,
      depending on the type of stream and the ability of the server
      to queue and/or reply it.  The server MAY drop low-priority
      messages in favour of high-priority messages.
    </doc>
  </field>

lib/Net/AMQP/Protocol/v0_8.pm  view on Meta::CPAN

    last as long as the channel they were created on, or until the
    client cancels them.
  </doc>
  <doc name = "rule">
    The server SHOULD support at least 16 consumers per queue, unless
    the queue was declared as private, and ideally, impose no limit
    except as defined by available resources.
  </doc>
  <doc name = "rule">
    Streaming applications SHOULD use different channels to select
    different streaming resolutions. AMQP makes no provision for
    filtering and/or transforming streams except on the basis of
    priority-based selective delivery of individual messages.
  </doc>
  <chassis name = "server" implement = "MUST" />
  <response name = "consume-ok" />

  <field name = "ticket" domain = "access ticket">
    <doc name = "rule">
      The client MUST provide a valid access ticket giving "read" access
      rights to the realm for the queue.

spec/amqp0-10.xml  view on Meta::CPAN

            and redeliver it to the same client at a later stage.
          </doc>
        </rule>
      </field>
    </command>

  </class>

  <!-- == Class: stream ======================================================================== -->

  <class name="stream" code="0xa" label="work with streaming content">
    <doc>
      The stream class provides commands that support multimedia streaming. The stream class uses
      the following semantics: one message is one packet of data; delivery is unacknowledged and
      unreliable; the consumer can specify quality of service parameters that the server can try to
      adhere to; lower-priority messages may be discarded in favor of high priority messages.
    </doc>

    <doc type="grammar">
      stream  = C:QOS S:QOS-OK
              / C:CONSUME S:CONSUME-OK
              / C:CANCEL
              / C:PUBLISH content

spec/amqp0-10.xml  view on Meta::CPAN

        <doc>
          Specifies a pre-fetch window in terms of whole messages. This field may be used in
          combination with the prefetch-size field; a message will only be sent in advance if both
          pre-fetch windows (and those at the session and connection level) allow it.
        </doc>
      </field>

      <field name="consume-rate" type="uint32" label="transfer rate in octets/second">
        <doc>
          Specifies a desired transfer rate in octets per second. This is usually determined by the
          application that uses the streaming data. A value of zero means "no limit", i.e. as
          rapidly as possible.
        </doc>

        <rule name="ignore-prefetch">
          <doc>
            The server MAY ignore the pre-fetch values and consume rates, depending on the type of
            stream and the ability of the server to queue and/or reply it.
          </doc>
        </rule>

spec/amqp0-10.xml  view on Meta::CPAN

      <rule name="min-consumers">
        <doc>
          The server SHOULD support at least 16 consumers per queue, unless the queue was declared
          as private, and ideally, impose no limit except as defined by available resources.
        </doc>
      </rule>

      <rule name="priority-based-delivery">
        <doc>
          Streaming applications SHOULD use different sessions to select different streaming
          resolutions. AMQP makes no provision for filtering and/or transforming streams except on
          the basis of priority-based selective delivery of individual messages.
        </doc>
      </rule>

      <implement role="server" handle="MUST" />

      <response name="consume-ok" />

      <field name="queue" type="queue.name">

spec/amqp0-8.xml  view on Meta::CPAN

</method>

</class>

  <class name="stream" handler="channel" index="80">
    <!--
======================================================
==       STREAMING
======================================================
-->
  work with streaming content

<doc>
  The stream class provides methods that support multimedia streaming.
  The stream class uses the following semantics: one message is one
  packet of data; delivery is unacknowleged and unreliable; the consumer
  can specify quality of service parameters that the server can try to
  adhere to; lower-priority messages may be discarded in favour of high
  priority messages.
</doc>

<doc name = "grammar">
    stream              = C:QOS S:QOS-OK
                        / C:CONSUME S:CONSUME-OK

spec/amqp0-8.xml  view on Meta::CPAN

      field may be used in combination with the prefetch-size field;
      a message will only be sent in advance if both prefetch windows
      (and those at the channel and connection level) allow it.
    </doc>
  </field>

  <field name = "consume rate" type = "long">
    transfer rate in octets/second
    <doc>
      Specifies a desired transfer rate in octets per second. This is
      usually determined by the application that uses the streaming
      data.  A value of zero means "no limit", i.e. as rapidly as
      possible.
    </doc>
    <doc name = "rule">
      The server MAY ignore the prefetch values and consume rates,
      depending on the type of stream and the ability of the server
      to queue and/or reply it.  The server MAY drop low-priority
      messages in favour of high-priority messages.
    </doc>
  </field>

spec/amqp0-8.xml  view on Meta::CPAN

    last as long as the channel they were created on, or until the
    client cancels them.
  </doc>
  <doc name = "rule">
    The server SHOULD support at least 16 consumers per queue, unless
    the queue was declared as private, and ideally, impose no limit
    except as defined by available resources.
  </doc>
  <doc name = "rule">
    Streaming applications SHOULD use different channels to select
    different streaming resolutions. AMQP makes no provision for
    filtering and/or transforming streams except on the basis of
    priority-based selective delivery of individual messages.
  </doc>
  <chassis name = "server" implement = "MUST" />
  <response name = "consume-ok" />

  <field name = "ticket" domain = "access ticket">
    <doc name = "rule">
      The client MUST provide a valid access ticket giving "read" access
      rights to the realm for the queue.

spec/amqp0-9.xml  view on Meta::CPAN

            sophisticated tracking to hold the message on the queue and redeliver it to
            the same client at a later stage.
          </doc>
        </rule>
      </field>
    </method>
  </class>

  <!-- ==  STREAM  =========================================================== -->

  <class name = "stream" handler = "channel" index = "80" label = "work with streaming content">
    <doc>
      The stream class provides methods that support multimedia streaming. The stream class
      uses the following semantics: one message is one packet of data; delivery is
      unacknowledged and unreliable; the consumer can specify quality of service parameters
      that the server can try to adhere to; lower-priority messages may be discarded in favour
      of high priority messages.
    </doc>
    
    <doc type = "grammar">
      stream              = C:QOS S:QOS-OK
                          / C:CONSUME S:CONSUME-OK
                          / C:CANCEL S:CANCEL-OK

spec/amqp0-9.xml  view on Meta::CPAN

          Specifies a prefetch window in terms of whole messages. This field may be used
          in combination with the prefetch-size field; a message will only be sent in
          advance if both prefetch windows (and those at the channel and connection level)
          allow it.
        </doc>
      </field>
      
      <field name = "consume-rate" domain = "long" label = "transfer rate in octets/second">
        <doc>
          Specifies a desired transfer rate in octets per second. This is usually
          determined by the application that uses the streaming data. A value of zero
          means "no limit", i.e. as rapidly as possible.
        </doc>

        <rule name = "01">
          <!-- TODO: Rule split? -->
          <doc>
            The server MAY ignore the prefetch values and consume rates, depending on
            the type of stream and the ability of the server to queue and/or reply it.
            The server MAY drop low-priority messages in favour of high-priority
            messages.

spec/amqp0-9.xml  view on Meta::CPAN

        <doc>
          The server SHOULD support at least 16 consumers per queue, unless the queue was
          declared as private, and ideally, impose no limit except as defined by available
          resources.
        </doc>
      </rule>

      <rule name = "02">
        <doc>
          Streaming applications SHOULD use different channels to select different
          streaming resolutions. AMQP makes no provision for filtering and/or transforming
          streams except on the basis of priority-based selective delivery of individual
          messages.
        </doc>
      </rule>

      <chassis name = "server" implement = "MUST" />
      <response name = "consume-ok" />

      <field name = "ticket" domain = "access-ticket">
        <rule name = "01">

spec/qpid.amqp0-8.xml  view on Meta::CPAN

</method>

</class>

  <class name="stream" handler="channel" index="80">
    <!--
======================================================
==       STREAMING
======================================================
-->
  work with streaming content

<doc>
  The stream class provides methods that support multimedia streaming.
  The stream class uses the following semantics: one message is one
  packet of data; delivery is unacknowleged and unreliable; the consumer
  can specify quality of service parameters that the server can try to
  adhere to; lower-priority messages may be discarded in favour of high
  priority messages.
</doc>

<doc name = "grammar">
    stream              = C:QOS S:QOS-OK
                        / C:CONSUME S:CONSUME-OK

spec/qpid.amqp0-8.xml  view on Meta::CPAN

      field may be used in combination with the prefetch-size field;
      a message will only be sent in advance if both prefetch windows
      (and those at the channel and connection level) allow it.
    </doc>
  </field>

  <field name = "consume rate" type = "long">
    transfer rate in octets/second
    <doc>
      Specifies a desired transfer rate in octets per second. This is
      usually determined by the application that uses the streaming
      data.  A value of zero means "no limit", i.e. as rapidly as
      possible.
    </doc>
    <doc name = "rule">
      The server MAY ignore the prefetch values and consume rates,
      depending on the type of stream and the ability of the server
      to queue and/or reply it.  The server MAY drop low-priority
      messages in favour of high-priority messages.
    </doc>
  </field>

spec/qpid.amqp0-8.xml  view on Meta::CPAN

    last as long as the channel they were created on, or until the
    client cancels them.
  </doc>
  <doc name = "rule">
    The server SHOULD support at least 16 consumers per queue, unless
    the queue was declared as private, and ideally, impose no limit
    except as defined by available resources.
  </doc>
  <doc name = "rule">
    Streaming applications SHOULD use different channels to select
    different streaming resolutions. AMQP makes no provision for
    filtering and/or transforming streams except on the basis of
    priority-based selective delivery of individual messages.
  </doc>
  <chassis name = "server" implement = "MUST" />
  <response name = "consume-ok" />

  <field name = "ticket" domain = "access ticket">
    <doc name = "rule">
      The client MUST provide a valid access ticket giving "read" access
      rights to the realm for the queue.