Een bridge beheren

Operatornotities voor het draaien van de bridge en de ring erachter: een plan laden, een herstart overleven, bijdrage laten doorstromen en de engine van het internet af houden.

De gateway (publiek toegangspunt) en de bridge (het gezicht van de engine) zijn de twee langlevende services die een operator gezond houdt, met daarachter de p4-agents en hun stage-servers. De engine spreekt helemaal geen authenticatie — hij gaat ervan uit dat machines die elkaar kunnen bereiken dat ook horen te doen — dus alles wat publiek is komt samen op de gateway, en de bridge wordt via een tunnel bereikt in plaats van gepubliceerd.

• Plaatsing is een plan dat je schrijft, geen verzoek dat je doet: de bridge antwoordt 409 aan wie hem vraagt te serveren. Genereer het plan, draai het droog, en laad het daarna met --confirm.
• De load generation wordt naar schijf geschreven voordat het eerste commando vertrekt. Hij wordt gekozen door de lader, bij elke sessie en bij elke unload op exacte gelijkheid gecontroleerd, en nergens op de machines vastgelegd — raak je hem kwijt, dan kan een geladen model niet eens meer worden afgebroken.
• De node generation is datzelfde getal. Laad een ring met twee verschillende getallen en hij serveert precies één verzoek voordat de kop stopt; de volgende sessie blijft halfgeladen hangen. Gebruik per load een verse waarde, anders botst een registratie die een mislukte poging heeft achtergelaten ermee.
• De agent weigert te laden zonder zijn operationele journaal. Dat is de toelatingsregistratie die een replay-veilige load nodig heeft, geen debugvlag.

• Een herstart van een agent laat zijn nodes vallen. Stage-servers bestaan alleen tijdens runtime; het model moet opnieuw uit het plan worden geladen. Dat is de herstelprocedure, niet het falen ervan.
• De gateway herlaadt het niet voor je. Zijn ring-watchdog merkt op dat een model niet meer serveert, leert uit de 409 van de bridge dat plaatsing extern is, zegt dat één keer en stopt met vragen.
• Bijdragetellers leven in het geheugen van de bridge. De gateway pollt elke 30 s en schrijft het verschil bij; een herstart verliest alleen wat nog niet was opgehaald, en de gateway herbaseert in plaats van dubbel te betalen wanneer een teller terugloopt.

• Bind de bridge op loopback en geef hem een service-token. Zonder dat token authenticeert hij niemand, en alles wat hem bereikt kan de ring gratis draaien — hij zegt dat bij het opstarten, in plaats van je het later te laten ontdekken.
• Agents adverteren het adres dat andere agents bellen. Gebruik het snelste netwerk dat de hosts delen, nooit loopback tussen hosts, en houd dat netwerk van het publieke internet af.
• Moet er iets op een publiek IP staan, onthoud dan dat Dockers gepubliceerde poorten ge-DNAT worden vóór de INPUT-chain, dus een regel op dport matcht niet. Filter in de DOCKER-USER-chain op de originele bestemmingspoort van conntrack (--ctorigdstport), en persisteer met een systemd-oneshot geordend After=docker.service.

• Een niet-ingestelde operator-wallet leest als nul verdiensten. De gateway slaat elke bijdrageregel zonder eigenaar over en logt er niets over. De nodes lijken stil te staan terwijl ze serveren.
• `pkill` matcht zijn eigen commandoregel. ssh host 'pkill -f server.js; ...' doodt de shell die het draait. Zet het patroon in een scriptbestand in plaats van in het remote commando, gebruik een character class (server[.]js), en onthoud dat een proces dat als kale node server.js is gestart geen pad heeft om op te matchen — vind het dan via zijn luisterpoort.