TC$mC$ on arkkitehtuurillisesti todella kypsC$ oivallus! Puhumme nyt
hajautettujen jC$rjestelmien klassisesta **Scatter-Gather** (Hajauta ja
kerC$C$) -mallista. YhdistettynC$ tiukkaan UNIX-filosofiaan, jossa ohjelmien
(ja komentojen) tulisi kommunikoida puhtaalla datalla, olet iskenyt kiinni
tC$smC$lleen oikeaan ongelmaan: miten hallita monimutkaista verkkotilaa
rikkomatta putkien (`|`) yksinkertaisuutta.

Pohdintasi osui naulan kantaan jokaisessa kohdassa. Ratkaistaan nC$mC$ JS-Bash
-hiekkalaatikkomme ehdoilla.

### 1. Aikaikkuna (Odotusaika)

Koska dynaamisessa ja hajautetussa verkossa emme koskaan voi tietC$C$, *kuinka
monta* solmua siellC$ on vastaamassa, emme voi jC$C$dC$ odottamaan "kaikkia".
MeidC$n on mC$C$riteltC$vC$ **aikaikkuna (Time Window)**.

Voimme luoda uudelle komennolle (kutsutaan sitC$ vaikka nimellC$ `bcast` eli
broadcast) sisC$C$nrakennetun parametrin, joka pitC$C$ Promisen auki halutun
ajan. Vasta kun aika umpeutuu, putki vapautetaan eteenpC$in.

* Esimerkki: `bcast /network/status --wait=250` (Kuuntelee vastauksia 250
millisekuntia).

### 2. Datan ja Metadatan tiukka erottelu

TC$mC$ on ehdottomasti tC$rkein pointtisi ketjutettavuuden kannalta. Jos
putkitat komennon (`bcast /logs | grep "error"`), `grep` haluaa nC$hdC$ vain
lokirivejC$. Jos vastaus sisC$ltC$C$ reititystietoja, solmujen ID:itC$ ja
viiveitC$ samassa rakenteessa datan kanssa, seuraavan komennon on pakko olla
tietoinen verkkoarkkitehtuurista, mikC$ rikkoo modulaarisuuden.

Erotetaan nC$mC$ kaksi maailmaa tC$ysin toisistaan ympC$ristC6muuttujissa:

* **`$RESULTS` (Puhdas hyC6tykuorma):** TC$mC$ on yksinkertainen lista
(Array). Jos kolme solmua vastaa palauttamalla rivin tekstiC$ tai
JSON-objektin, `$RESULTS` sisC$ltC$C$ vain nuo kolme asiaa perC$kkC$in. TC$mC$
sama data tulostetaan myC6s suoraan komennon `stdoutiin` (w), jotta putki
(`|`) voi jatkua saumattomasti eteenpC$in.
* **`$META` (Konepellin alainen tieto):** TC$mC$ on Map/Dict (JS-objekti),
joka avaimenaan kC$yttC$C$ solmun tai vastauksen uniikkia ID:tC$. TC$C$llC$
lepC$C$ latenssi, reitti ja alkuperC$inen vastausotsikko.

### 3. JS-viittaukset (Referenssit) muistin sC$C$stC$jC$nC$

Olit tC$ysin oikeassa JS-moottorin toiminnasta: voimme laittaa datan sekC$
listaan ettC$ mappiin ilman, ettC$ muistinkulutus kasvaa tavuakaan, koska JS
tallentaa oliot aina viitteinC$ (by reference).

Voimme rakentaa `bcast`-komennon taustalogiikan (teoreettisesti) nC$in
tehokkaaksi:

```javascript
/ Kun vastaus saapuu solmulta "Node_A":
const payload = { cpu: "45%" }; // Varsinainen data
const meta = { source: "Node_A", latency: 12, ttl: 64 };

/ 1. Luodaan uniikki ID tC$lle nimenomaiselle vastaukselle
const responseId = generateId();

/ 2. Sijoitetaan PCCDATA listaan indekseillC$ (automaatiota ja putkia varten)
env.RESULTS.push(payload);

/ 3. Sijoitetaan PCCDATA myC6s mappiin (tarkkoja hakuja varten)
env.RESULTS_MAP[responseId] = payload; // HUOM: Vain viittaus muistissa!

/ 4. Sijoitetaan META omaan mappiinsa samalla ID:llC$
env.META[responseId] = meta;

```

### KC$ytC$nnC6n hyC6dyt komentorivillC$

TC$llC$ arkkitehtuurilla skriptaus nousee tC$ysin uudelle tasolle. Jos teet
hiekkalaatikossasi lennosta JS-evaluointia (`${...}`), voit ristiinviitata
dataan ja metatietoon tC$ydellisesti:

1. **Suora putkitus:** `bcast /metrics --wait=100 | grep cpu`
*(Toimii tC$ydellisesti, koska bcast tulostaa vain `$RESULTS` -sisC$llC6n).*
2. **Datan poiminta indeksillC$:** `echo "Nopein solmu sanoi:
${RESULTS[0].cpu}"`
3. **Metadatan kaivaminen:** Jos huomaat, ettC$ kolmas vastaus (indeksi 2) oli
outo, voit kirjoittaa skriptin, joka katsoo metadatasta kuka sen lC$hetti:
`echo "Kolmannen vastauksen lC$hetti: ${META[Object.keys(META)[2]].source}"`

TC$mC$ malli tukee valtavan hienosti myC6s niitC$ asynkronisia protokollia,
joissa data yhdistetC$C$n lennosta konfliktivapaasti (esim. CRDT-tilojen
synkronointi verkon yli), koska voimme dumpata raakadatan prosessoitavaksi
suoraan putkeen, mutta pitC$C$ yksittC$isten pakettien metatiedot tallessa
taustalla, jos niitC$ tarvitaan myC6hemmin debuggaukseen tai reititykseen.

MiltC$ tC$llainen `bcast`-tyyppinen Scatter-Gather -komento tuntuisi lisC$tC$
hiekkalaatikkomme mikrosyntaksiin? Haluatko, ettC$ luonnostelemme sen `cmd.js`
-tiedostoon, ja simuloimme samalla selaimen Service Workerissa tilanteen,
jossa "virtuaaliverkko" vastaa tarkoituksella useilla viiveellC$ tulevilla
JSON-paketeilla?