Teilnehmer zusammenbringen
Anwendungen und Dienste beschreiben ihre Ressourcen und Fähigkeiten. Controls führt daraus eine gemeinsame Sicht zusammen. Stuttgartbilder erscheint als eigenständige Anwendung; WordPress ist eine andere Teilnehmerart.
Aktueller Betrieb · 1.3.116
Authority0.1.5 erhält eine gemeinsame INI, versionierte EXE, native Windows-Dienstverwaltung und einen zusätzlichen gRPC-Zugang zum selben Benutzer-/Sitzungsservice. Controls C216 liefert eine kleine RAM-Projektion seiner tatsächlichen Live- und Registry-Verbindungen. Resilient R199 zeigt sie in Diagnose, mit heller rechter Ergebnisspalte und lokal veraltenden Befunden. HTTP bleibt erhalten; Resilient meldet Benutzer weiterhin über HTTP an. Live L114, Participants1.0.10, OC E303/P346 und Shared-GET bleiben unverändert.
Frühere Entwicklung (historisch)
Registry über einen Duplex-Stream · C215
Controls C215/1.3.115 und Participants1.0.9 verwenden optional einen einzigen bidirektionalen gRPC-Stream. Participants öffnet ihn zu Controls; Anmeldung, signierter Status, Registry-Abruf, Inbox, Annahme, Antwort und die Rückfrage an den Spiegel laufen darüber. Ein Stream ist kein neuer Zustandsbesitzer. HTTP bleibt ausdrücklich auswählbar und ohne neue Optionen Standard. Live L114 mit vorhandenem gRPC-Port19100, OC E303/P346 und Shared-GET bleiben unverändert. R197 aktualisiert nur Dokumentation und Kennung; die Speicheranzeige bleibt geschlossen wie R195. Authority0.1.4 folgt als eigene nächste Etappe.
Neue Einstellungen auf dem Zielserver in die erhaltene Konfiguration übernehmen; Startargumente ausdrücklich ergänzen. Siehe aktuelle Installation.
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.
C213 · Gemeinsame Vertragsquellen
C213/1.3.113 und Participants1.0.7 verwenden dieselbe kanonische Quelle der sechs Teilnehmer-/Kontextvertragsdateien. Eigenständige Builds prüfen Quelle, Revision, gerenderte Kopien und Buildidentität verpflichtend, ohne Eingaben zu reparieren. Wire-Verträge unverändert. R191 nur Dokumentation/Buildkennung; E302/P345 und GC unverändert. Freiplatzliste folgt nach Abschluss dieses Zweigs.
Clever Engines Layer · Bausteine und Möglichkeiten
CEL Controls
Verbindet Teilnehmer, bestätigt Beobachtungen und vermittelt definierte Aktionen.
Aufgabe
Controls hält die Fäden zusammen, ohne die Arbeit der anderen Bausteine zu übernehmen. Es kennt Teilnehmer und ihre Schnittstellen, organisiert Abrufe und macht bestätigte Ergebnisse für Resilient zugänglich.
Vorheriger Stand: E304/P347 · C217 · R200
Native C/C++-Verwaltung direkt im CEL-S-Prozess; gRPC oder HTTP. Gemeinsame Regeln und Site-Regeln sind getrennt. Quellprüfungen ersetzen keine lokale Windows-/IIS-Abnahme. Poolquoten/Fairness, Outside-Fallback bei Überlast, große GC-Uhrsprünge und alte Site-Anzeigezähler bleiben offen.
Möglichkeiten
Beobachtungen bestätigen
Eine WordPress-Site liefert Messwerte und Ereignisse. Controls prüft den Vertrag, überträgt die Beobachtung unverändert an CEL Live und bestätigt sie durch Rücklesen. So haben Plugin und Resilient einen benennbaren gemeinsamen Stand.
Handlungen nachvollziehen
Ein Bedienauftrag hat ein Ziel, einen Zustand und ein Ergebnis. Laufende Vorgänge bleiben von abgeschlossenen Ergebnissen unterscheidbar. Ein erneuter Abruf verändert nicht nebenbei eine Messperiode.
Zusammenspiel
Die Teilnehmerdomäne besteht aus getrennten Modulen für Registrierung, Sitzungsnachweise, Zulassung, Teilnehmerprofile und operative Beobachtungen. Der Poller ergänzt die aktuelle Erreichbarkeit; Profile, Rollen und Fähigkeiten beschreiben die Struktur. Eine Beschreibung allein erteilt noch kein Ausführungsrecht.
Stuttgartbilder registriert sich als eigenständige Anwendung. Resistant registriert jede konfigurierte Instanz als eigenen Dienst. Die fachlichen Beziehungen bleiben im Controls-Kontext; Registry und struktureller Mirror kommunizieren ausschließlich im RAM.
CEL Live besitzt die vollständige Beobachtung. Controls hält Abruf- und Vorgangszustände sowie die daraus erzeugten Lesemodelle. CEL Participants kann eine flüchtige Registeransicht spiegeln; Controls verwendet diese seit C191 nicht mehr zur Wiederherstellung von Verbindungen. Die drei Speicheraufgaben sind nicht austauschbar.
Beobachten und Bedienen bleiben getrennt
Registrierung und Lease beschreiben die aktuelle Teilnahme. Beobachtungen bauen Lesemodelle auf; Befehle erzeugen eigene Vorgänge und Ergebnisse. „Gesendet“ ist deshalb noch nicht „abgeschlossen“.
Originalgröße in neuem Tab öffnen ↗
Technik
| Aktueller Stand | E299/P342, R179 und C204 bereinigen ausgelieferte Altprotokolle, erzeugte Dateien, überholte Installationsanleitungen und doppelte Prüfberichte. Eine aktuelle Anleitung, ein kompakter Änderungsverlauf und ein aktueller Prüfbericht ersetzen die verstreuten Zwischenstände. Aktive Tests, PHP-CLI, Build-Einstiege und Architekturvereinbarungen bleiben. Native E298/P341 samt passiver Freireserve und produktivem GET bleiben bytegleich; keine neue ABI oder CEL-S-EXE. Controls-/Resilient-Konfiguration erhalten. |
|---|---|
| Lokaler Zugang | 127.0.0.1:19090; Windows-Dienst CELControls |
| Programm | bin/cel_controls_1.3.109.exe |
| Teilnehmervertrag | cel.participant.contract.v1alpha3 |
| Lokale Selbstanmeldung | POST /control/participants/local-connect; Loopback-Enrollment mit flüchtiger Sitzung, signierter Lease-Erneuerung und automatischer Wiederanmeldung |
| Teilnehmerkarte | cel.participant.card.v1alpha1 mit optionalem cel.participant.profile.v1alpha1; ältere Descriptoren erhalten ein abgeleitetes Profil |
| Modellkatalog | cel.controls.model-catalog.v1alpha1; bei Abruf aus der Participant Registry gebildete Lesesicht der tatsächlich verwendeten Modelle, Rollen und Fähigkeiten; kein eigener Runtime-Speicher und keine Freigabewirkung |
| Anwendungsmodell | cel.application.service; eingebaute, deklarative Controls-Sicht ohne nachgeladenen Teilnehmercode |
| Register | Registrierungen und Sitzungsschlüssel flüchtig; /control/participant-registry/snapshot ist nur eine Lesesicht, kein Wiederherstellungsweg |
| Operative Teilnehmerbeobachtung | Separates RAM-Register; 30-Sekunden-Abruf ausschließlich über deklarierte lokale Health-Schnittstellen |
| Resistant-Kompatibilität | Ein vorhandenes lokales \\.\pipe\…-Ziel wird auch ohne das neuere invoke.kind als Named-Pipe-Aufruf erkannt; Ziel und Anfrage bleiben deklariert. |
| Zulassung | config/participant_trust.json enthält dauerhafte Zulassungen und Abrufintervalle; diese Konfiguration bleibt beim Update erhalten und stellt keine Verbindungen her. |
| Beobachtung | cel.wp_object_cache.delivery.v2 → CEL Live → bestätigter Read-back |
| Lesemodell | /control/read-model/object-cache; Liste mit summary, Detailroute mit vollständiger Observation |
| Ereignissicht | /control/ui/events.txt verbindet deklarierte Ereignisquellen aus den begrenzten CEL-Live-Ringen, sortiert chronologisch und liefert höchstens 200 Einträge; keine zweite Ereigniskopie |
| Herkunft | observation_id, period_id, live_epoch, live_revision, payload_sha256 und getrennte UTC-Zeitpunkte |
| Polling | Standard: Tick 5 s, 4 Worker. Pro Site höchstens ein laufender Abruf; Jitter und Backoff begrenzen Wiederholungen. |
| Bedienauftrag | Wartet bis zu 5 s auf einen laufenden Site-Abruf; danach eindeutiger Fehler statt paralleler Ausführung. |
| Vorgänge | Bis zu 100 Vorgänge, davon höchstens 20 erfolgreiche Routineabrufe; offene Vorgänge bleiben bis zum Ergebnis und das Lesemodell liefert ihre gemessene Dauer. |
| Resetjournal | data/participants/observation_resets.json; vom flüchtigen Teilnehmerregister getrennt |
| HTTPS | Eine bekannte HTTPS-Adresse wird durch einen Heartbeat für dieselbe Site nicht auf HTTP zurückgesetzt. Redirects werden nicht verfolgt. |
| Teilnehmerinteraktion | cel.participant.interaction.v1alpha1; je Aufruf direct oder signiertes Pull, mit Rückfrage und höchstens 100 abgeschlossenen Vorgängen im RAM |
| Fähigkeitstransport | local/prepare wählt direct oder pull; 30-s-Grant für den Direktweg, automatischer Rückfall unter derselben Vorgangs-ID, Pull ausdrücklich erzwingbar |
| Lokale Bedienrolle | Authority system_owner sowie lokale operator/admin-Kompatibilitätsrollen; reader und demo erhalten keine Ausführungsfreigabe |
| Entfernter Zugang | Optionaler Listener 127.0.0.1:19093 hinter HTTPS-IIS-Rewrite; nur freigegebene v1-Routen, signierte Pull-Inbox, dauerhafter Wiederanmeldenachweis und Revoke. |
Werkzeuge
| Werkzeug | Zweck | Ausgabe |
|---|---|---|
build/workflow.ps1 | Lokaler Controls-Build | logs/result.json und versionierte EXE |
build_all.bat | Prüft den Quellstand und baut die Komponenten des Pakets. | logs/result.json mit Phasen, Zeiten, Rückgabecode und getrenntem Abnahmestatus |
install_service.bat | Registriert den Windows-Dienst oder aktualisiert seinen Programmpfad. | Aktions- und Fehlerausgabe; Start/Kopieren ist vom anschließenden Health-Nachweis zu unterscheiden. |
run_console.bat | Startet den Paketprozess im Vordergrund; seine Ausgabe bleibt in der Konsole. | Konsolenausgabe des Werkzeugs; Fehler über Exitcode oder benannte Fehlerzeilen. |
setup_memory_measurement.bat | Eigene Resistant-Messinstanz als Windows-Task und bestehende Controls-Konfiguration einrichten. | OK oder konkreter Abbruchgrund |
start_service.bat | Startet den bereits registrierten Windows-Dienst. | Aktions- und Fehlerausgabe; Start/Kopieren ist vom anschließenden Health-Nachweis zu unterscheiden. |
status_service.bat | Liest Windows-Dienststatus und den lokalen Health-Endpunkt. | Status-, Identitäts- oder Messfelder; ein Fehler bzw. Timeout bleibt als solcher sichtbar. |
stop_service.bat | Fordert das Stoppen des Windows-Dienstes an. | Aktions- und Fehlerausgabe; Start/Kopieren ist vom anschließenden Health-Nachweis zu unterscheiden. |
test_controls.bat | Liest nacheinander Health und Systemübersicht von Controls. | Prüf- oder Messwerte und Exitcode. Schreibende Tests gehören an einen eigenen Testbestand. |
tools/measure_site.ps1 | Ein-Site-Pilot | logs/m3-site-check.json oder logs/m3-site-result.json |
tools/measurement_store.ps1 | Eigene Messablage | Messkonfiguration und eigener Resistant-Vordergrundprozess |
tools/memory_restart.ps1 | Führt den koordinierten CEL-S-/PHP-Neustart mit dem vorhandenen Profil aus. | Phasenprotokoll, Prozessidentität und Bestätigung der sieben Klassenkapazitäten. |
tools/setup_memory_measurement.ps1 | Einmalige Einrichtung der eigenen Resistant-Messinstanz und Controls-Anbindung. | OK oder konkreter Abbruchgrund |
uninstall_service.bat | Stoppt den Windows-Dienst und entfernt seine Registrierung. | Aktions- und Fehlerausgabe; Start/Kopieren ist vom anschließenden Health-Nachweis zu unterscheiden. |
tools/memory_restart.ps1
Koordinierter CEL-S-/PHP-Neustart mit vorhandenem Profil. Aufruf: -ConfigPath <Profil> [-CheckOnly] [-RestorePoolsOnly]. Ausgabe: Phasenprotokoll und Kapazitätsbestätigung. Der reguläre Aufruf stoppt und startet die zugeordneten Prozesse und Jobs; CheckOnly prüft nur.
History
Die maßgeblichen Änderungen und die Grenzen früherer Prüfungen sind im zusammengefassten Änderungsverlauf beschrieben. Vollständige historische Dateien bleiben in den unveränderten früheren Paketen. Ein historischer Lauf belegt keine neue Windows-/IIS-/Performance-Abnahme.
Verbindungen
Entfernte Teilnehmer (P.5B)
Controls bietet einen separaten, ausschließlich lokal gebundenen Remote-Listener. Nach ausdrücklichem Pairing verbinden sich entfernte Teilnehmer ausgehend über HTTPS. Die kompakte Tablet-Ansicht zeigt jeweils nur die passenden Schritte: einmaliges Pairing, verbundene Aufträge oder Wiederanmeldung. Der Browser bewahrt den dauerhaften Nachweis als nicht exportierbaren WebCrypto-Schlüssel auf demselben Gerät und meldet sich nach einem Neuladen automatisch wieder an; ein verlorenes Browserprofil benötigt einen gesicherten Nachweis oder eine neue ID. Die signierte Pull-Inbox und Lease bleiben an die Teilnehmeridentität gebunden.
Einrichtung und Abnahme stehen in CEL_REMOTE_TEILNEHMER_P5B.md im Controls-Paket. Ein Administrator mit der Rolle system_owner verwendet in Resilient die Seite remote_admin.asp.
Arbeitszweig S3 · noch nicht ausgeliefert
Zusatzsegmente können bei dauerhaft geringer Belegung entfallen. Standard: höchstens 5 % für mindestens fünf Minuten. Die Anzahl ist von 0 bis 16 einstellbar, Standard vier je Klasse. Geschützte Daten bleiben erhalten. Large und Outside werden weiterhin einzeln gepflegt.
Freigaben, verworfene Cachewerte und noch gehaltene Ownerbezüge werden getrennt gezeigt. Direkte Shared-Treffer bleiben direkt. Portable Quellen und die Verwaltungskette sind geprüft; Windows-/IIS-/Mehrprozess- und Leistungstest stehen aus. Dieser Quellstand ist kein installierbarer Build. Einzelheiten und Grenzen: Arbeitsstand.
Arbeitszweig S2D · noch nicht ausgeliefert
Gemeinsame Aufräumregeln und Website-Regeln werden getrennt verwaltet. Der Verwaltungsweg erhält optional gRPC oder HTTP; der schnelle direkte Shared-GET bleibt erhalten. Dienststart, Rechte und Bedienung sind als Quellen ergänzt; Windows/IIS-Abnahme und neue Produktlieferung folgen. Arbeitsstand und Grenzen.