Live über gRPC · erster Pilot

Controls C214 und Live L114 ergänzen den ausdrücklich wählbaren gRPC-Weg. HTTP und gRPC benutzen denselben Live-Speicher. Originale Beobachtungsbytes und getrennte Hash-/Epoch-/Revisionsbestätigung bleiben erhalten. Participants1.0.8, Authority0.1.4 und OC E303/P346 bleiben unverändert; kein RPC im Shared-GET. R196 synchronisiert nur Dokumentation und Buildkennung. Bestehende INI-Dateien bleiben erhalten; ohne neue Optionen weiterhin HTTP.

Aktivierung ausdrücklich in beiden INI-Dateien. Live-Port19094 ist ein konfigurierbares Loopback-Beispiel; bestehende HTTP-Ports bleiben erhalten. Der tatsächliche gRPC-Health-Aufruf und ein frisch bestätigter Site-Abruf zeigen die Übernahme.

[grpc]
enabled=true
bind=127.0.0.1:19094

[live_state]
transport=grpc
grpc_target=127.0.0.1:19094

Ein normaler Build je Komponente, gezielte Nebenläufigkeitsprüfung und echte private Prozesskette bestanden. Windows-Zielkompilierung bestanden; tatsächlicher Windows-Dienst-/IIS-Lauf noch lokal offen. Kein Shared-GET- oder E302-Vergleich aus dieser Prüfung ableiten.

Clever Engines Layer · Bausteine und Möglichkeiten

CEL Live

Hält unveränderte Beobachtungen und einen begrenzten Ereignisstrom im Arbeitsspeicher.

Paketstand 1.0.14 · Wissensstand 28. Oktober 2026

L113: klarer Live-Speicherkern

L113/1.0.13 trennt Live-Speicherkern und Anwendungsabläufe vom HTTP-Adapter sowie von Konfiguration und Dienststart. Rohdaten, Hash, Revisionen, Ereignisring und atomarer Reset bleiben erhalten. R192 aktualisiert Dokumentation und Buildkennung. C213/Participants1.0.7, E302/P345 und die Speicheranzeige bleiben unverändert.

Zuerst die inneren Grenzen von Participants und Authority abschließen, dann aktive Freiplatzliste mit gezieltem Mehr-Worker-Stressprogramm. Tatsächliches gRPC danach als eigener Zweig. Nach dem Freiplatzlistentest die Speicheranzeige auf nutzbaren Bestand, Kapazität/Belegung und Handlungsbedarf konzentrieren; Details aufklappbar, kurze einfache Hinweise für Administratoren, Operatoren und Entwickler.

Installation und lokale Abnahme

E270: 24 Stunden und Betriebsanzeigen

Basis: E265 / P307 / R124. Jetzt P312, R129, Controls 1.3.85, Live 1.0.12 und Memory Setup 1.1.5. Neue Windows-Binaries sind lokal zu bauen und abzunehmen.

Gemeinsame Spitzen und Engpässe: rollierende 24 Stunden im Minutenraster (höchstens 60 Sekunden Nachlauf). Beobachtungszeit zählt reale Sekunden im Fenster; Stillstand zählt nicht. Alte Tagesmaxima werden nicht umetikettiert. Faktor, Regeln und Vormerkung bleiben erhalten. config-cache und persönliche config-Verzeichnisse erhalten.

OC und Resilient vergleichen dieselben Fair-GET-Dreiergruppen. Unvollständige Klassen werden ausgelassen, bestätigte Fehler separat gezeigt. Neustartstatus wird bis zum Abschluss geprüft; danach wird eine neue Aufnahme angefordert. Ereignisse lassen sich zentral vollständig löschen, ohne Messungen und Cachewerte zurückzusetzen.

Die damalige Installationsanleitung bleibt im unveränderten E270-Paket.

Aufgabe

Live bewahrt das, was ein Teilnehmer tatsächlich beobachtet hat. Es interpretiert keine Messwerte und ergänzt keine fehlenden Felder. Dadurch lässt sich eine Anzeige auf genau eine Beobachtung zurückführen.

Möglichkeiten

Einen Stand wiederfinden

Pro Topic und Subject liegt eine vollständige Observation mit den ursprünglichen Bytes. Epoch, Revision, Speicherzeit und SHA-256 stehen daneben und verändern den Inhalt nicht.

Ereignisse verfolgen

Ein begrenzter Ring hält Meldungen je Teilnehmer. Wiederholte Event-IDs mit gleichem Inhalt sind idempotent; ein anderer Inhalt unter derselben ID ist ein Konflikt.

Gezielt zurücksetzen

State und Ereignisse können einzeln oder gemeinsam zurückgesetzt werden. Der gemeinsame Reset besitzt eine ID, damit eine Wiederholung denselben Auftrag erkennt.

Zusammenspiel

Controls schreibt und liest über den lokalen HTTP-Vertrag. Ein Topic fasst zusammengehörige Beobachtungen zusammen; das Subject identifiziert den einzelnen Teilnehmer. Die Oberfläche bezieht ihren Stand über Controls, nicht durch einen zweiten direkten Zugriff auf Live.

Bei jedem Live-Neustart beginnt eine neue Epoch. Es gibt keine Wiederherstellung alter Beobachtungen von der Platte. Innerhalb einer Epoch steigt die Revision auch über einen Reset hinweg weiter.

Technik

Standardadresse	127.0.0.1:19091
Windows-Dienst	CELLiveObjectCacheObservation
Programm	bin/cel_live_1.0.14.exe nach lokalem Go-Build
State	PUT / GET / DELETE /v2/state/{topic}/{subject}
Sammelabruf	GET /v2/state/{topic}; Subjects stabil sortiert
Ereignisse	POST / GET / DELETE /v2/events/{topic}/{subject}
Reset	POST /v2/reset/{topic}/{subject} mit reset_id; State und Ereignisse unter einem Lock
Grenze je Body	Standard 524288 Byte; konfigurierbarer Bereich 128 KiB bis 4 MiB
Ereignisring	50 Einträge je Subject, neuester zuerst
Zeit	RFC3339 mit UTC-Offset; Z und +00:00 werden akzeptiert
Konsistenz	stored_at_utc, revision, epoch, payload_sha256 außerhalb der Nutzdaten

Zustände und Betriebsgrenzen

Eine erreichbare Live-Instanz kann nach einem Neustart leer sein. OBSERVATION_NOT_AVAILABLE beschreibt dann den fehlenden Beobachtungsstand, nicht zwangsläufig einen abgestürzten Prozess. Der nächste erfolgreiche Controls-Poll liefert eine neue vollständige Beobachtung.

Bei einem Paketaustausch bleiben die lokalen Bestände getrennt vom Quell- und Programmstand erhalten: config/, logs/.

Werkzeuge

Alle BAT- und PowerShell-Dateien dieses Pakets, einschließlich der internen Aufrufwege. Die Wirkung unterscheidet reine Abfragen, lokale Prüfungen und Eingriffe. Web-Abfragen sind davon getrennt.

Paketwurzel · 8 Werkzeuge

Name	Zweck	Aufruf, Ausgabe und Wirkung
`build_all.bat`Build	Prüft den Quellstand und baut die Komponenten des Pakets.	Buildphasen, Zielpfade und Compiler-/Prüfergebnis; bei Fehlern kein erfolgreicher Abschluss. Wirkung: schreibt BuildausgabenAufrufweg: `verify_service.bat`
`install_service.bat`Betrieb	Registriert den Windows-Dienst oder aktualisiert seinen Programmpfad.	Aktions- und Fehlerausgabe; Start/Kopieren ist vom anschließenden Health-Nachweis zu unterscheiden. Wirkung: verändert Zustand
`run_console.bat`Betrieb	Startet den Paketprozess im Vordergrund; seine Ausgabe bleibt in der Konsole.	Konsolenausgabe des Werkzeugs; Fehler über Exitcode oder benannte Fehlerzeilen. Wirkung: liestAufrufweg: `build_all.bat`
`start_service.bat`Betrieb	Startet den bereits registrierten Windows-Dienst.	Aktions- und Fehlerausgabe; Start/Kopieren ist vom anschließenden Health-Nachweis zu unterscheiden. Wirkung: verändert Zustand
`status_service.bat`Diagnose	Liest Windows-Dienststatus und den lokalen Health-Endpunkt.	Status-, Identitäts- oder Messfelder; ein Fehler bzw. Timeout bleibt als solcher sichtbar. Wirkung: liest
`stop_service.bat`Betrieb	Fordert das Stoppen des Windows-Dienstes an.	Aktions- und Fehlerausgabe; Start/Kopieren ist vom anschließenden Health-Nachweis zu unterscheiden. Wirkung: verändert Zustand
`uninstall_service.bat`Betrieb	Stoppt den Windows-Dienst und entfernt seine Registrierung.	Aktions- und Fehlerausgabe; Start/Kopieren ist vom anschließenden Health-Nachweis zu unterscheiden. Wirkung: verändert Zustand
`verify_service.bat`Diagnose	Prüft Existenz, Dienstregistrierung und Health von CEL Live, ohne den Dienst neu zu starten.	Windows-Dienststatus und Health-JSON; Exit 0 bei erfolgreicher Prüfung, sonst 1/2. Wirkung: liest

History

Unveränderte Beobachtung

Feldmischungen und parallele Messwertkopien wurden durch einen Rohbyte-Vertrag ersetzt.

Getrennte Ereignisse

Ereignisse erhielten stabile IDs und einen eigenen, begrenzten Ring.

Eindeutige Neustart- und Reset-Semantik

Epoch, Revision und Reset-ID trennen einen neuen Dienstlauf von einem fachlichen Reset.