> For the complete documentation index, see [llms.txt](https://medomicslab.gitbook.io/medfl-app-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://medomicslab.gitbook.io/medfl-app-docs/medfl-review/medfl-package-review/real-world.md).

# Real world

### Overview

The **real-world mode** of MEDfl executes federated learning in a distributed setting where the **server** and **clients** run as independent processes. Unlike simulation mode, real-world mode is designed to reproduce practical deployment conditions, including client orchestration, connectivity constraints, and asynchronous behavior.

In this review, the real-world mode is executed using **separate notebooks** to represent each component:

* **one notebook for the central server**, and
* **one notebook per client**.

This approach mirrors a real deployment while keeping the review workflow reproducible and easy to execute.

### Purpose of this review

The objective of this review is to **validate the correctness and stability of MEDfl when operating under real-world execution conditions**, with an emphasis on:

* correct initialization and launch of the server process,
* client registration and connectivity behavior,
* consistent execution of training rounds across distributed clients,
* correct aggregation and evaluation on the server side,
* robust handling of common real-world events (late client, disconnect, retry),

### Notebook-based execution design

For consistency and reproducibility, the real-world test is executed with the following notebook structure:

* **Server notebook**
  * starts the federated server
  * defines aggregation strategy and evaluation procedure
  * writes server logs and final artifacts
* **Client notebooks (one per client)**
  * load client-local dataset portion
  * run local training when instructed by the server
  * send updates to the server
  * write client logs and (optional) local artifacts

> Each notebook is executed independently (potentially on different machines), which reproduces real-world separation while maintaining a controlled review setup.

### Documentation and tutorials

The following resources describe how simulation mode is implemented and used in MEDfl.

<table data-card-size="large" data-view="cards"><thead><tr><th></th></tr></thead><tbody><tr><td><a href="https://medfl.readthedocs.io/en/latest/simulation_tutorials.html">Simulation mode documentation</a></td></tr></tbody></table>

### Getting Started with the Tutorial

To start testing MEDfl using this tutorial, simply visit this [**GitHub repository** ](https://github.com/ouaelesi/MEDfl-package-review)and download the **tutorial notebook along with the provided datasets**.

The GitHub repository used for this review is organized into four main folders:

`/models :` Contains the pretrained model used for transfer learning experiments.\
This model is loaded during training to initialize the federated learning process when transfer learning is enabled.

`/data :` Contains the dataset files already partitioned across multiple clients.\
Each file represents the local dataset of a specific client, simulating decentralized data ownership.

`/rw :` Contains the notebooks used for the **Real-World Mode review**.\
These notebooks are intended to be executed separately by the server and each client on different machines.

Once downloaded, you can run the notebooks locally and follow the tutorial to reproduce the results and experiment with different configurations.

#### Running the Real-World Scenario

To successfully run the real-world federated learning experiment, the notebooks must be executed **in a specific order**:

1. **Start the server notebook first**\
   The server will launch and wait for clients to connect.
2. **Run the client notebooks one by one**

{% hint style="warning" %}
When you run the client make sure to replace the server ip adress with the actual server adress&#x20;
{% endhint %}

To get the server adress you can use this command on the server machine&#x20;

```bash
hostname -I
```

Once you get the adress test the connectivity, from a client machine run this command and replace the ip adress with the actual one

```shellscript
ping 13.356.54.6
```

You must something like this&#x20;

```python
from MEDfl.rw.client import FlowerClient , DPConfig

client = FlowerClient(
    server_address="0.0.0.0:8080", # Replace the 0.0.0.0 with the server adress ex. 12.23.65.45:8080
    data_path="../data/clients/client_3_dataset.csv",
    dp_config=None,
)

if __name__ == "__main__":
    client.start()
```

\
Each time a client notebook is started, you can return to the server notebook to verify in the logs that the client has successfully connected.

<figure><img src="https://2289920470-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FOpYh7tOQkAu0q6hPpqe9%2Fuploads%2FXkxTcCOzAeQPimSnGvou%2FCapture%20d%E2%80%99%C3%A9cran%20du%202026-02-03%2015-12-32.png?alt=media&amp;token=17593211-f03b-423c-8cff-fb625f3231a7" alt=""><figcaption></figcaption></figure>

This order is essential to ensure proper coordination between the server and the clients during training.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://medomicslab.gitbook.io/medfl-app-docs/medfl-review/medfl-package-review/real-world.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
