aboutsummaryrefslogtreecommitdiffstats
path: root/src/dma/vendor/github.com/streadway/amqp/doc.go
diff options
context:
space:
mode:
authorToshiaki Takahashi <takahashi.tsc@ncos.nec.co.jp>2018-09-06 09:04:29 +0000
committerToshiaki Takahashi <takahashi.tsc@ncos.nec.co.jp>2018-09-07 06:03:01 +0000
commitd61931341176dad9ccff7c967a10d88fe54218fa (patch)
tree526457882d4abe0c38d2242d6daa311bf8ef51cf /src/dma/vendor/github.com/streadway/amqp/doc.go
parent73abc060f31a6bf866fa1dad0a1a6efdfd94d775 (diff)
src: Add DMA localagent
Change-Id: Ibcee814fbc9a904448eeb368a1a26bbb69cf54aa Signed-off-by: Toshiaki Takahashi <takahashi.tsc@ncos.nec.co.jp>
Diffstat (limited to 'src/dma/vendor/github.com/streadway/amqp/doc.go')
-rw-r--r--src/dma/vendor/github.com/streadway/amqp/doc.go108
1 files changed, 108 insertions, 0 deletions
diff --git a/src/dma/vendor/github.com/streadway/amqp/doc.go b/src/dma/vendor/github.com/streadway/amqp/doc.go
new file mode 100644
index 00000000..76bf3e58
--- /dev/null
+++ b/src/dma/vendor/github.com/streadway/amqp/doc.go
@@ -0,0 +1,108 @@
+// Copyright (c) 2012, Sean Treadway, SoundCloud Ltd.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+// Source code and contact info at http://github.com/streadway/amqp
+
+/*
+Package amqp is an AMQP 0.9.1 client with RabbitMQ extensions
+
+Understand the AMQP 0.9.1 messaging model by reviewing these links first. Much
+of the terminology in this library directly relates to AMQP concepts.
+
+ Resources
+
+ http://www.rabbitmq.com/tutorials/amqp-concepts.html
+ http://www.rabbitmq.com/getstarted.html
+ http://www.rabbitmq.com/amqp-0-9-1-reference.html
+
+Design
+
+Most other broker clients publish to queues, but in AMQP, clients publish
+Exchanges instead. AMQP is programmable, meaning that both the producers and
+consumers agree on the configuration of the broker, instead requiring an
+operator or system configuration that declares the logical topology in the
+broker. The routing between producers and consumer queues is via Bindings.
+These bindings form the logical topology of the broker.
+
+In this library, a message sent from publisher is called a "Publishing" and a
+message received to a consumer is called a "Delivery". The fields of
+Publishings and Deliveries are close but not exact mappings to the underlying
+wire format to maintain stronger types. Many other libraries will combine
+message properties with message headers. In this library, the message well
+known properties are strongly typed fields on the Publishings and Deliveries,
+whereas the user defined headers are in the Headers field.
+
+The method naming closely matches the protocol's method name with positional
+parameters mapping to named protocol message fields. The motivation here is to
+present a comprehensive view over all possible interactions with the server.
+
+Generally, methods that map to protocol methods of the "basic" class will be
+elided in this interface, and "select" methods of various channel mode selectors
+will be elided for example Channel.Confirm and Channel.Tx.
+
+The library is intentionally designed to be synchronous, where responses for
+each protocol message are required to be received in an RPC manner. Some
+methods have a noWait parameter like Channel.QueueDeclare, and some methods are
+asynchronous like Channel.Publish. The error values should still be checked for
+these methods as they will indicate IO failures like when the underlying
+connection closes.
+
+Asynchronous Events
+
+Clients of this library may be interested in receiving some of the protocol
+messages other than Deliveries like basic.ack methods while a channel is in
+confirm mode.
+
+The Notify* methods with Connection and Channel receivers model the pattern of
+asynchronous events like closes due to exceptions, or messages that are sent out
+of band from an RPC call like basic.ack or basic.flow.
+
+Any asynchronous events, including Deliveries and Publishings must always have
+a receiver until the corresponding chans are closed. Without asynchronous
+receivers, the sychronous methods will block.
+
+Use Case
+
+It's important as a client to an AMQP topology to ensure the state of the
+broker matches your expectations. For both publish and consume use cases,
+make sure you declare the queues, exchanges and bindings you expect to exist
+prior to calling Channel.Publish or Channel.Consume.
+
+ // Connections start with amqp.Dial() typically from a command line argument
+ // or environment variable.
+ connection, err := amqp.Dial(os.Getenv("AMQP_URL"))
+
+ // To cleanly shutdown by flushing kernel buffers, make sure to close and
+ // wait for the response.
+ defer connection.Close()
+
+ // Most operations happen on a channel. If any error is returned on a
+ // channel, the channel will no longer be valid, throw it away and try with
+ // a different channel. If you use many channels, it's useful for the
+ // server to
+ channel, err := connection.Channel()
+
+ // Declare your topology here, if it doesn't exist, it will be created, if
+ // it existed already and is not what you expect, then that's considered an
+ // error.
+
+ // Use your connection on this topology with either Publish or Consume, or
+ // inspect your queues with QueueInspect. It's unwise to mix Publish and
+ // Consume to let TCP do its job well.
+
+SSL/TLS - Secure connections
+
+When Dial encounters an amqps:// scheme, it will use the zero value of a
+tls.Config. This will only perform server certificate and host verification.
+
+Use DialTLS when you wish to provide a client certificate (recommended),
+include a private certificate authority's certificate in the cert chain for
+server validity, or run insecure by not verifying the server certificate dial
+your own connection. DialTLS will use the provided tls.Config when it
+encounters an amqps:// scheme and will dial a plain connection when it
+encounters an amqp:// scheme.
+
+SSL/TLS in RabbitMQ is documented here: http://www.rabbitmq.com/ssl.html
+
+*/
+package amqp