Using peer-to-peer communication¶

Peer-to-peer functionality is defined in a service and the Kanzi Connect Server does not participate in related decisions. When you run a service in the same process as the Kanzi Connect Server, all communication goes through an existing client-server connection, and never through peer-to-peer communication.

When you run a service remotely, first the client establishes a connection to the Kanzi Connect Server and then creates a session towards the selected service.

../../_images/peer-to-peer-connection.png

Response to this start session operation contains XML format routing instructions that tell the client what links it must establish towards the service and which messages must be routed to which link.

By default, a service creates two special peer-to-peer endpoints that are always available without any further configuration:

Reliable. Provides a reliable peer-to-peer communications link between the service and the client. Bearer of the reliable link is the same as the remote service uses to connect to the server in a first place.
Unreliable. Provides an unreliable peer-to-peer communications link between the service and the client. Bearer is explicitly configured and with remoteservicerunner executable that is connect.bearer.udp.

This implementation uses a simple peer-to-peer approach which includes these functionality limitations:

Only one active route can exist for a specific remote service resource (method, event, or runtime data) so each client must access a specific service resource with the same mechanism. To overcome this limitation, the coming releases will provide more flexible runtime configuration options.
Bearers do not support inter-system communication (like shared memory), which makes it easy to configure the system in a way that it makes it unable to communicate properly.

Using built-in reliable peer-to-peer link¶

Defining objects link to “reliable” uses a default peer-to-peer link between client and service. The communication protocol is the same as that used by the remote service to connect the server. This means that if remoteservice connects to a server using SSL protocol, then the default reliable peer-to-peer link for that same service is also SSL.

<service name=”ForkedRuntimeData”>
  <routing>
    <route link="reliable" linkType="direct">
      <runtimedata/>
    </route>
    <route link="reliable" linkType="server">
      <runtimedata/>
    </route>
  </routing>
</service>

Using built-in unreliable peer-to-peer link¶

Defining objects link to “unreliable” uses a default built-in unreliable peer-to-peer link between client and service. The communication protocol is defined programmatically and with remoteservicerunner application it is defined to connect.bearer.udp. The only supported protocol for unreliable communication is UDP.

<service name=”ForkedRuntimeData”>
  <routing>
    <route link="unreliable" linkType="direct">
      <runtimedata/>
    </route>
    <route link="unreliable" linkType="server">
      <runtimedata/>
    </route>
  </routing>
</service>

../../_images/p2p-built-in-unreliable.png

Configuring a service to use unreliable peer-to-peer link¶

The only unreliable bearer in Kanzi Connect is connect.bearer.udp. To use the UDP bearer in unreliable mode, you must explicitly configure it using the reliable_link attribute.

Note

It is always recommended to define timeout for method that returns a value and that is going to be delivered over unreliable bearer. Without the timeout in case of a lost packet Kanzi Connect can wait indefinitely for the method response, which consumes related memory.

<service name=”DirectLinkService”>
  <routing>
    <route link="unreliable_p2p" linkType="direct" bearer="connect.bearer.udp" reliable_link="false">
      <method name="callMeDirect"/>
      <event name="signalMeDirect"/>
    </route>
  </routing>
  <method name=”callMeDirect” timeout=”5000” return=”void”/>
  <event name=”signalMeDirect” />
  <method name=”callMeViaServer”/>
  <event name=”signalMeViaServer”/>
</service>

../../_images/p2p-configure-unreliable.png

Configuring a service to publish runtime data to server and clients¶

Even though runtime data is mostly used by a Kanzi Connect Client, in some cases you must deliver it to a Kanzi Connect Server too. For example, when:

Runtime data contains values required by the Kanzi Connect Server policy functionality.
You want to expose runtime data to HTTP.

In this scenario a dedicated route definition direct_and_server is used with runtime data definition. For server delivery the services primary connection towards server is always used. For direct peer-to-peer transfer you can define the link either explicitly or use one of the built-in links.

<service name=”ForkedRuntimeData”>
  <routing>
    <route link="rt_link" linkType="direct" bearer="connect.bearer.tcp>
      <runtimedata/>
    </route>
    <route link="rt_link" linkType="server" bearer="connect.bearer.tcp>
      <runtimedata/>
    </route>
  </routing>
  <runtime-data>
    <value type=”int”/>
  </runtime-data>
</service>

../../_images/service-publish-runtime-data.png

Troubleshooting peer-to-peer configuration¶

The protocol for a peer-to-peer communication is set by a service. For example, a service can require an SSL peer-to-peer connection even when a Kanzi Connect Client is not connected to a Kanzi Connect Server using SSL.

When a peer-to-peer connection requires a different protocol, in Kanzi Studio when the Preview starts it shows this error.

../../_images/p2p-different-protocol-error.png

To fix this error, in Kanzi Studio set the connection adapter that has the bearer type connect.bearer.ssl and has the SSL required security material configured.