Architecture

We are using a lot of terms that have been explained in the glossary before, so we assume you are aware of their meaning and won't got into detail here anymore.

The communication between DRD and remote sites is always initiated by DRD. The remote sites have to have the DRD Agent installed but that agent is completely passive and does only respond to requests from DRD where each request is encrypted and authenticated - more details about security. Each remote site and their agents can be configured to listen to multiple DRD instances if you like. This is useful where multiple parties, like e.g. your IT department and your external Drupal agency, are monitoring your sites.

Again, the agent is a lightweight piece of code with the only purpose the receive requests from DRD, maybe execute some actions, and finally respond to the request that has been made. If DRD wants the agent to execute an action on the remote site, it brings its code for doing this with it. This has been implemented this way so that DRD can grow over time and you only have to update your main DRD instance to benefit from new functionality - and not all of your remote sites. The code that will be accepted by the agents is limited to what is provided by the third project in this family, the DRD Library.

The DRD library is compiled into a phar file and contains all functionality for all 3 Drupal versions that are supported by DRD for remote site: Drupal 6, 7, 8 or later.

In DRD everything is built around entities.