TC$mC$ on erittC$in mielenkiintoinen ja arkkitehtuurisesti syvC$ aihe.
Hajautetun viestintC$verkoston ja pakettireitityksen suunnittelu ilman suoraa
riippuvuutta perinteisistC$ TCP/IP-osoitteista (kuten IP-osoitteet ja portit)
nojaa vahvasti **overlay-verkkojen (Overlay Networks)** ja **sisC$ltC6keskeisen
 verkotuksen (Content-Centric Networking, CCN)** periaatteisiin.

Tietokonehistoriassa ja nykystandardeissa on useita hienoja malleja, joista
voimme ottaa parhaat opit tC$hC$n Mesh-reititysarkkitehtuuriin.

---

## 1. Paketin rakenne: Sanoman kC$C$re (Envelope Protocol)

Jotta paketti voi liikkua eri ympC$ristC6jen (Browsers, FastAPI, Hauki-X86,
LPT-kanavat) vC$lillC$, sen tC$ytyy olla standardoidusti "koteloitu".

JSON-pohjainen pakettiformaatti voisi noudattaa tietokonehistorian tunnettuja
periaatteita (**RFC 5322 / BGP / Bundle Protocol RFC 4838**):

```json
{
  "head": {
    "v": 1,
    "id": "msg_9f8a3b11-2026",
    "src": "mesh://hauki-obs/chrome/tab_57B254FA",
    "dst": "mesh://*/gemini/*",
    "type": "BROADCAST",
    "ttl": 10,
    "timestamp": 1784793000,
    "trace": ["hauki-obs", "hauki-teacher"]
  },
  "route": {
    "target_type": "HUD_INSTANCE",
    "eval_condition": "typeof window.TELEPATH_HUD_ACTIVE !== 'undefined'"
  },
  "payload": {
    "action": "UPDATE_THEME",
    "data": { "color": "#00ff41" }
  }
}

```

### OtsakekentC$t (Header breakdown):

* **`src` & `dst` (URI-pohjainen osoitteistus):** Looginen osoite muodossa
`mesh://[HOST]/[ENGINE]/[INSTANCE]`. Jokainen taso voi kC$yttC$C$
villikortteja (`*`).
* **`ttl` (Time-To-Live / Hop Count):** EstC$C$ ikuiset silmukat
reitityksessC$. Jokainen yhdyskC$ytC$vC$ (gateway) vC$hentC$C$ luvusta 1.
* **`trace` (ReittijC$lki):** EstC$C$ pakettia palaamasta samaan solmuun,
jossa se on jo kC$ynyt.

---

## 2. Osoitteistus ja reititysmallit

Historia tuntee kolme pC$C$sC$C$ntC6istC$ tapaa ohjata paketteja, joista
voimme yhdistellC$ parhaat puolet:

| Reititystapa | Historiallinen / Standardi esikuva | Miten toimii MeshissC$?
|
| --- | --- | --- |
| **PisteestC$ pisteeseen (Unicast)** | IP-reititys, UUCP, X.25 | Kohdeosoite
on tarkka: `mesh://hauki-obs/chrome/tab_123` |
| **Aihepohjainen (Pub/Sub / Anycast)** | MQTT, AMQP, Matrix | Kohde
mC$C$ritellC$C$n tyypin mukaan: `mesh://*/hud/status` |
| **Ehtopohjainen (Attribute / Eval)** | Content-Centric Networking (NDN) |
Paketti toimitetaan kaikille instansseille, jotka tC$yttC$vC$t ehdon (esim.
tietty muuttuja olemassa). |

---

## 3. Mahalliset toteutustasot

### Taso 1: Saman hostin sisC$inen Tab-to-Tab -reititys (Local Fan-Out)

Saman koneen sisC$llC$ `mailbox_worker.js` toimii lokaalina kytkimenC$
(L2-kytkin):

```
[Tab A (MBOX)] ---> [Mailbox Worker / Gateway] ---> [Tab B (MBOX)]
                                              ---> [Tab C (MBOX)]

```

1. Tab A lC$hettC$C$ paketin osoitteeseen `mesh://localhost/chrome/*`.
2. Mailbox Worker hakee paketin `MBOX_OUT`-laatikosta.
3. Worker katsoo osoitetta (`/chrome/*`), pyytC$C$ FastAPI-sillalta kaikkien
active-tabien ID:t, ja puskee paketin kaikkien saman koneen tabien
`MBOX_IN`-laatikkoon.

---

### Taso 2: Airgap / Viiveensietoinen reititys (DTN & LPT1 / Hauki-X86)

Kun siirretC$C$n dataa fyysisesti rajoitettujen vC$ylien yli (LPT1-rinnakkaispo
rtti, sarjaportti tai offline-tiedostot), kC$ytetC$C$n **Store-and-Forward**
-mallia (sama periaate kuin **UUCP**:ssC$ 1980-luvulla tai **RFC 4838 Bundle
Protocol**:ssa avaruustietoliikenteessC$):

```
[Chrome Tab] ---> [Host GW] ===(LPT1 / Serial)===> [Airgap GW] ---> [Hauki-X86
Kernel]

```

* **Offline-hoppaus:** Jos Hauki-X86 ei ole valmiina ottamaan vastaan
pakettia, `Host GW` tallentaa paketin paikalliseen puskuriin (esim.
`/mnt/mesh_root/spool/out/`).
* **LPT-emulaattori / Airgap:** Gateway lukee puskurista paketteja ja
siirtC$C$ ne LPT1/sarjavC$ylC$n lC$pi tavu kerrallaan. Hauki-X86-kernelin
puolella oleva vastaanotin parsii JSON-paketin ja sijoittaa sen kernelin
sisC$iseen postilaatikkoon.

---

## 4. IRC-verkon hyC6dyntC$minen reititystaulun jakamiseen (Gossip / Control
Plane)

**PC$C$telmC$si IRC:n hyC6dyntC$misestC$ on erinomainen.** Internetin
ydinkytkimet kC$yttC$vC$t BGP-protokollaa (Border Gateway Protocol)
kertoakseen toisilleen *"minun kauttani pC$C$see nC$ihin verkkoihin"*. Voit
kC$yttC$C$ IRC-kanavaa (esim. `#mesh-routing`) tC$ysin vastaavaan
**Gossip-protokollaan**.

### Miten IRC Control Plane toimisi?

1. **Topologian mainostus (Heartbeat / LSA):**
Jokainen kC$ynnistyvC$ Gateway lC$hettC$C$ 30-60 sekunnin vC$lein
IRC-kanavalle lyhyen JSON-ilmoituksen:
```json
{
  "tag": "!mesh-announce",
  "gw_id": "hauki-obs",
  "routes": [
    "mesh://hauki-obs/chrome/*",
    "mesh://hauki-obs/fastapi/*"
  ],
  "capabilities": ["HUD_RENDERER", "BASIC_ENGINE"]
}

```


2. **Reititystaulun muodostaminen (Routing Table):**
Jokainen Mesh Gateway kuuntelee `#mesh-routing`-kanavaa ja yllC$pitC$C$
muistissaan dynamista reititystaulukkoa:

| KohdekUVIO (Pattern) | Seuraava hyppy (Next Hop) | Tyyppi / Ominaisuudet |