Connection Types
Public
Allows synchronization of data with an instance, which you can access from your side and is available in a public network.Private
Allows synchronization of data with an instance, which is behind the firewall and you cannot access it from the public network.Local connection
Allows synchronization of data between projects within the same instance.
Public/ Private Connection Synchronization
With Exalate it is possible to set up synchronization between a public and a private instance without opening firewall ports.
The main difference between private and public connection types is whether the HTTP/HTTPS requests are initiated from one side or from both sides.
In the private-public connection, all communication over TCP/IP is initiated from the private side. In this case, the public side never sends HTTP requests. It only answers requests sent from the instance, located behind the firewall. Because of this, it might take a couple of extra seconds before synchronization continues.
The private instance (one behind the firewall) sends a request for any changes either every 20 seconds or whenever there are changes to sync towards the public instance. This explains the delay in sync in case there are no changes in the private to push to the public. This parameter can be modified, but 20 seconds seems to be an acceptable delay.
Note: For better performance, we recommend configuring one connection. You can add multiple conditions to the Sync Rules to cover all the affected projects.
In the public-public connection, requests are initiated from both sides.
Exalate has a set of messages (supported by private-public communication).
The table below details the messages that are sent between the nodes.
Message | When Performed | How Public Instance sends it? | How Private Instance sends it? |
|---|---|---|---|
| node info | instance is saved / connection is tested | private instance requests public's node info, the public instance responds to it | is sent via the email when you set up private/public sync |
| sync request | something was changed on an issue, which is under sync | private instance periodically polls, whether the public instance has any sync requests | private instance sends sync requests directly |
| sync response | synchronization has been processed by the receiving side | private instance periodically polls, whether the public instance has any sync responses | private instance sends sync responses directly |
| sync error response | synchronization failed on the receiving side due to the sending side's mistake | private instance periodically polls, whether the public instance has any sync error responses | private instance sends sync error responses directly |
| blob request | an attachment was added to an issue, which is under sync | private instance periodically polls, whether the public instance has any attachments to be sent | private instance sends blob requests directly |
| blob response | an attachment has been received by receiving side | private instance periodically polls, whether the public instance received an attachment being synced | private instance sends blob responses directly |
| blob error response | synchronization of an attachment failed on receiving side due to sending side's mistake | private instance periodically polls, whether the public instance had any problems with receiving an attachment | private instance sends blob error responses directly |
Note: To switch from an existing connection from public/public to public/private (or reverse) you need:
- An update of the database on both sides
- All synchronization transactions are fully handled (queues are empty)
In case of need please reach out to our support (here)