xaynet-client-0.1.0 doesn't have any documentation.
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.
# Participant
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`].
# Client
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.
[`check_task`]: #method.check_task
[`compose_update_message`]: #method.compose_update_message
[`compose_sum_message`]: #method.compose_sum_message
[`compose_sum2_message`]: #method.compose_sum2_message
[`start()`]: #method.start
[`during_round()`]: #method.during_round