The router implements a software layer that abstracts the details of a protocol implementation from the higher layer router logic. It is analogous to the typical application/device-driver layering common in operating systems. In the router's case the "device driver" layer is implemented via protocol adaptors while the "application" layer implements protocol-agnostic logic, such as routing and management operations.
For example, qdr_connection_t is the router's abstraction of a network connection. It is used by various parts of the router that are not directly involved in performing I/O.
The I/O layer instantiates a corresponding connection control entity that implements the I/O and connection control logic for the protocol running on that connection. For example the AMQP protocol uses a qd_connection_t to manage the proton AMQP connection. TCP uses a qd_tcp_connection_t to manage a proton raw connection.
The multi-protocol aspect of the router is a fairly new feature. Previously the only protocol supported for data transfer was the AMQP protocol. Since multi-protocol was not an original design goal the AMQP protocol software was closely coupled with the higher level router software.
Now that the protocol adaptor layer has been implemented I would like to try refactoring the existing AMQP protocol code to use the protocol adaptor layer.
The first step in this process would be to create an adaptor subdirectory dedicated for the AMQP protocol code and moving as much AMQP I/O code into it. This would involve moving code that operates on qd_connection_t (and its children - qd_link_t, qd_session_t, etc), AMQP connector and AMQP listener code.
The router implements a software layer that abstracts the details of a protocol implementation from the higher layer router logic. It is analogous to the typical application/device-driver layering common in operating systems. In the router's case the "device driver" layer is implemented via protocol adaptors while the "application" layer implements protocol-agnostic logic, such as routing and management operations.
For example, qdr_connection_t is the router's abstraction of a network connection. It is used by various parts of the router that are not directly involved in performing I/O.
The I/O layer instantiates a corresponding connection control entity that implements the I/O and connection control logic for the protocol running on that connection. For example the AMQP protocol uses a qd_connection_t to manage the proton AMQP connection. TCP uses a qd_tcp_connection_t to manage a proton raw connection.
The multi-protocol aspect of the router is a fairly new feature. Previously the only protocol supported for data transfer was the AMQP protocol. Since multi-protocol was not an original design goal the AMQP protocol software was closely coupled with the higher level router software.
Now that the protocol adaptor layer has been implemented I would like to try refactoring the existing AMQP protocol code to use the protocol adaptor layer.
The first step in this process would be to create an adaptor subdirectory dedicated for the AMQP protocol code and moving as much AMQP I/O code into it. This would involve moving code that operates on qd_connection_t (and its children - qd_link_t, qd_session_t, etc), AMQP connector and AMQP listener code.