| Qpid C++ AMQP implementation |
| ============================= |
| |
| = Project layout = |
| |
| For Build system design see comment at start of Makefile. |
| |
| Project contains: |
| * Client library (lib/libqpid_client): src/qpid/client |
| * Broker library (lib/libqpid_broker): src/qpid/broker |
| * Common classes |
| * src/qpid/framing: wire encoding/decoding |
| * src/qpid/sys: io, threading etc |
| * src/qpid/Exception.cpp, QpidError.cpp: Exception classes. |
| * Qpid Daemon (bin/qpidd): src/qpidd.cpp |
| |
| Unit tests in test/unit: each *Test.cpp builds a CppUnit plugin. |
| |
| Client tests in test/client: each *.cpp builds a test executable. |
| |
| Test utilities: test/include |
| |
| = Client Design = |
| |
| The client module is primarily concerned with presenting the |
| functionality offered by AMQP to users through a simple API that |
| nevertheless allows all the protocol functionality to be exploited. |
| [Note: it is currently nothing like complete in this regard!] |
| |
| The code in the client module is concerned with the logic of the AMQP |
| protocol and interacts with the lower level transport issues through |
| the InputHandler and OutputHandler abstractions defined in |
| common/framing. It uses these in conjunction with the Connector |
| interface, defined in common/io, for establishing a connection to the |
| broker and interacting with it through the sending and receiving of |
| messages represented by AMQFrame (defined in common/framing). |
| |
| The Connector implementation is responsible for connection set up, |
| threading strategy and getting data on and off the wire. It delegates |
| to the framing module for encode/decode operations. The interface |
| between the io and the framing modules is primarily through the Buffer |
| and AMQFrame classes. |
| |
| A Buffer allows 'raw' data to be read or written in terms of the AMQP |
| defined 'types' (octet, short, long, long long, short string, long |
| string, field table etc.). AMQP is defined in terms frames with |
| specific bodies and the frame (as well as these different bodies) are |
| defined in terms of these 'types'. The AMQFrame class allows a frame |
| to be decoded by reading from the supplied buffer, or it allows a |
| particular frame to be constructed and then encoded by writing to the |
| supplied buffer. The io layer can then access the raw data that |
| 'backs' the buffer to either out it on the wire or to populate it from |
| the wire. |
| |
| One minor exception to this is the protocol initiation. AMQP defines |
| a protocol 'header', that is not a frame, and is sent by a client to |
| intiate a connection. The Connector allows (indeed requires) such a |
| frame to be passed in to initialise the connection (the Acceptor, when |
| defined, will allow an InitiationHandler to be set allowing the broker |
| to hook into the connection initiation). In order to remove |
| duplication, the ProtocolInitiation class and the AMQFrame class both |
| implement a AMQDataBlock class that defines the encode and decode |
| methods. This allows both types to be treated generically for the |
| purposes of encoding. In decoding, the context determines which type |
| is expected and should be used for decoding (this is only relevant to |
| the broker). |
| |
| |
| |
| |
| --------api-------- |
| Client Impl ...............uses..... |
| input handler --> --------- --------- <-- output handler . |
| A | . |
| | | framing utils |
| | V . |
| ------------------- <-- connector . |
| IO Layer ................uses.... |