Struktur erhalten
Der Mirror übernimmt die Teilnehmerbeschreibung und deren Generation. Controls nutzt daraus höchstens bestehende Pollingpräferenzen; Verbindungen, URLs, Leases und Sessions werden nach Neustart nicht daraus wiederhergestellt.
Gemeinsame Konfiguration und Windows-Dienst · Participants1.0.10
Participants 1.0.10 erhält eine gemeinsame config/participants.ini für Windows-Dienst und Konsole sowie die native Dienstverwaltung CELParticipants. Die Startskripte enthalten keine eigenen Port- oder Transportvorgaben mehr. HTTP und der bestehende bidirektionale gRPC-Stream bleiben auswählbar; C215 und L114 bleiben unverändert. R198 aktualisiert Dokumentation und Kennung, die Speicheranzeige bleibt unverändert. OC E303/P346, Shared-GET, Authority und andere Produkte sind nicht betroffen.
Konfiguration in config/participants.ini; danach install_service.bat und start_service.bat. Siehe aktuelle Anleitung.
Registry über einen Duplex-Stream · Participants1.0.9
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.
Aktuell: Participants1.0.7 · 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 Participants
Erhält die strukturelle Teilnehmerregistrierung in einem eigenständigen RAM-Prozess.
Klare innere Zuständigkeiten
Participants1.0.8 trennt Mirror und Anmeldung/Lease/Inbox von HTTP. Authority0.1.4 trennt Benutzer-/Sessionregeln von Datei, Audit und HTTP. R193 aktualisiert die Dokumentation und Buildkennung. Controls C213, Live L113, E302/P345 und die Speicheranzeige bleiben unverändert.
Damit sind die vorgesehenen inneren Grenzen des Strukturzweigs vorbereitet. Nach lokaler Abnahme folgt die aktive Freiplatzliste mit gezieltem Stressprogramm über echte Mehr-Worker-Zugriffswege. Danach die Speicheranzeige straffen; tatsächliches gRPC als eigener Zweig.
Aufgabe
Participants ist der kleine Begleiter der Teilnehmerverwaltung. Während Controls neu startet, kann hier der zuletzt übernommene Registerstand weiterleben. Das Paket bleibt eigenständig startbar.
Möglichkeiten
Unabhängig laufen
Der Prozess ist weder Teil von IIS noch ein Kindprozess, den Controls zum Starten benötigt. Ein vollständiger Rechnerneustart leert auch diesen Speicher; neue Anmeldungen bauen die Sicht wieder auf.
Selbst anmelden
Der Mirror meldet seinen Descriptor lokal an, hält seine Lease signiert aktuell und verbindet sich nach einem Controls-Neustart automatisch neu. Das Werkzeug bleibt für gezielte Prüfungen verfügbar.
Zusammenspiel
Der Mirror liest den strukturellen Snapshot aus Controls. Eine unveränderte Generation ersetzt seinen gespeicherten Stand nicht. Der aktuelle Code ruft dabei den vollständigen Snapshot im Pull-Takt ab; die Generation verhindert die erneute Übernahme, nicht bereits den HTTP-Abruf.
Snapshot und Health sind unterschiedliche Aussagen: Der Prozess kann antworten, auch wenn noch kein Registerstand übernommen wurde. Deshalb gehören has_snapshot, Generation und Übernahmezeit zum technischen Befund.
Technik
| Prozess | bin/cel_participants_1.0.8.exe |
|---|---|
| Zugang | 127.0.0.1:19092; nur Loopback-Bindung |
| Pull | Standard 2 s; Anfragefrist 800 ms |
| Quelle | Controls /control/participant-registry/snapshot |
| Vertrag | cel.participant.registry.live.v1; Participant Descriptor aus cel.participant.contract.v1alpha3 einschließlich Profil, Modell, Rollen und Fähigkeiten |
| Lesen | GET /health; GET /v1/snapshot |
| Health | result, service, version, generation, has_snapshot, updated_at |
| Speicher | Ausschließlich RAM; keine Snapshot-Datei und kein Recovery nach vollständigem Rechnerneustart |
| Selbstanmeldung | Beim Start lokales Enrollment; danach alle 60 s signierte Statusmeldung und Lease-Erneuerung; automatische Wiederanmeldung nach Controls-Neustart |
| Werkzeug | tools/cel_participant_register.exe: register, renew, unregister, list, get, validate, issue-pairing |
Zustände und Betriebsgrenzen
has_snapshot=false bedeutet: Der Mirror läuft, hat aber noch keinen nutzbaren Registerstand. Eine Generation ist kein Frischebeweis für Messwerte. Ein restaurierter Teilnehmer muss seine aktuelle Erreichbarkeit wieder belegen.
Der rohe Registry-Snapshot ist ein interner Wiederherstellungskanal. Die öffentliche Dokumentation und das gemeinsame Diagnose-Terminal geben ihn nicht aus; für die Sicht auf Teilnehmer dient das bereinigte Lesemodell von Controls.
Der Mirror besitzt keinen dateibasierten Teilnehmerbestand. Seine Kontinuität hängt vom weiterlaufenden Prozess ab.
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 · 5 Werkzeuge
| Name | Zweck | Aufruf, Ausgabe und Wirkung |
|---|---|---|
build_all.batBuild | Prüft den Quellstand und baut die Komponenten des Pakets. | Buildphasen, Zielpfade und Compiler-/Prüfergebnis; bei Fehlern kein erfolgreicher Abschluss. Wirkung: schreibt Buildausgaben |
run_console.batBetrieb | Startet den Paketprozess im Vordergrund; seine Ausgabe bleibt in der Konsole. | Konsolenausgabe des Werkzeugs; Fehler über Exitcode oder benannte Fehlerzeilen. Wirkung: liest |
start.batBetrieb | Startet den eigenständigen Teilnehmer-Mirror als minimierten Prozess. | Aktions- und Fehlerausgabe; Start/Kopieren ist vom anschließenden Health-Nachweis zu unterscheiden. Wirkung: verändert Zustand |
status.batDiagnose | Liest den Health-Endpunkt des Teilnehmer-Mirrors. | Status-, Identitäts- oder Messfelder; ein Fehler bzw. Timeout bleibt als solcher sichtbar. Wirkung: liest |
stop.batBetrieb | Beendet den Teilnehmer-Mirror über seinen Prozessnamen. | Taskkill über Prozessnamen; der Aufruf beendet den RAM-Mirror hart. Der bestehende Wrapper meldet auch bei fehlendem Prozess Exit 0. Wirkung: beendet Prozesse hart |
History
Eigene Prozessgrenze
Die strukturelle Registry-Kopie wurde aus dem Controls-Prozess herausgelöst. Damit können Live-Verwaltung und Mirror unabhängig neu gestartet werden.
Kleine Paketgrenze
Der Paketname ist cel_participants. Der Server liegt in bin, das Registrierungswerkzeug in tools; Controls bringt keinen zweiten Teilnehmerprozess mit.
Strukturierte Teilnehmerbeschreibung
Der RAM-Mirror bewahrt Profil, Modell-ID, Rollen, Bindung, Revision und Hash unverändert zusammen mit der bestehenden Registrierung.
Lokale Selbstanmeldung
Der Mirror nutzt den gemeinsamen Loopback-Enrollment-Vertrag, liefert dabei sein eigenes Teilnehmerprofil, erneuert seine Lease mit signierten Statusmeldungen und verbindet sich nach einem Controls-Neustart selbst erneut.
Interaktionsbeschreibung erhalten
Der Mirror bewahrt auch Parameter-, Ergebnis- und Rückfragebeschreibungen einer Fähigkeit unverändert im strukturellen Snapshot.
P.5C: Teilnehmer und schmale Ansichten
CEL Participants bietet registry.mirror.status als begrenzte, signierte Pull-Fähigkeit an. Der vollständige Snapshot bleibt ausschließlich am internen Loopback-Zugang.