[][src]Module xaynet::client

Provides client-side functionality to connect to a XayNet service.

This functionality includes:

  • Abiding by (the underlying Participant's side of) the PET protocol.
  • Handling the network communication with the XayNet service, including polling of service data.


In any given round of federated learning, each Participant of the protocol is characterised by a role which determines its Task to carry out in the round, and which is computed by check_task.

Participants selected to Update are responsible for sending masked model updates in the form of PET messages constructed with compose_update_message.

Participants selected to Sum are responsible for sending ephemeral keys and global masks in PET messages constructed respectively with compose_sum_message and compose_sum2_message.


A Client has an intentionally simple API - the idea is that it is initialised with some settings, and then start()ed. Currently for simplicity, clients that have started running will do so indefinitely. It is therefore the user's responsibility to terminate clients that are no longer needed. Alternatively, it may be more convenient to run just a single round (or a known fixed number of rounds). In this case, use during_round(). For examples of usage, see the test-drive scripts.

Note. At present, the Client implementation is somewhat tightly coupled with the workings of the C-API SDK, but this may well change in a future version to be more independently reusable.

Requests via Proxy

There is a Proxy which a Client can use to communicate with the service. To summarise, the proxy:

  • Wraps either an in-memory service (for local comms) or a client request object (for remote comms over HTTP).
  • In the latter case, deals with logging and wrapping of network errors.
  • Deals with deserialization

The client request object is responsible for building the HTTP request and extracting the response body. As an example:

async fn get_sums(&self) -> Result<Option<bytes::Bytes>, reqwest::Error>

issues a GET request for the sum dictionary. The return type reflects the presence of networking Errors, but also the situation where the dictionary is simply just not yet available on the service. That is, the type also reflects the optionality of the data availability.

Proxy essentially takes this (deserializing the Bytes into a SumDict while handling Errors into ClientErrors) to expose the overall method

async fn get_sums(&self) -> Result<Option<SumDict>, ClientError>



A client of the federated learning service


A participant in the PET protocol layer.



Client-side errors


Proxy for communicating with the service.


Tasks of a participant.