Die Abwicklung von Rennen zwischen der Abfrage des vollen Status über RPC und veröffentlichten Deltas

Question

Ich bin im Begriff, ein System basierend auf Autobahn zu entwerfen. Ich bin Begegnung häufig das folgende Muster:

• Clients einen vollständigen Zustand über einen RPC Thema anfordern können - zum Beispiel alle Stimmen bei der Abstimmung Beispiel
• Updates zu diesem Zustand von dem Server veröffentlicht werden - zum Beispiel ein geänderte Abstimmung eines bestimmten Betreffs
• Clients behalten den aktuellen Status im Auge, indem sie den vollständigen Status und die Aktualisierungen kombinieren.

Das Problem ist folgendes:
Es ist ein potenzielles Rennen zwischen dem Staat und eine veröffentlichte Änderung der asynchronen Natur der Autobahn durch das Abfragen.
Während der Status auf der Serverseite berechnet wird, wird möglicherweise bereits ein Update an den Client gesendet. Sobald der Client den vollen Status erhält, ist er nicht mehr auf dem neuesten Stand. Es muss mit dem früher empfangenen Update gepatcht werden.

Irgendwie habe ich das Gefühl, dass dies ein häufiges Problem ist. Gibt es einige Best Practices für den Umgang mit diesem Fall?

ich so etwas wie dies am überlegen:

• Clients zuerst zum Update Thema abonniert und erst danach den RPC-Aufruf tun.
• Alle vom Server gesendeten Daten müssen mit einem Zeitstempel versehen sein.
• Wenn ein Update empfangen wird, bevor der RPC-Aufruf zurückgegeben wird, wird es gespeichert.
• Sobald der RPC-Aufruf eintrifft, patcht der Client den Status mit allen empfangenen Updates, die einen neueren Zeitstempel haben.

Macht das Sinn? Oder fehlt mir etwas Offensichtliches?

I slightly modified the crossbar vote example to show the problem.
Der RPC-Aufruf zur Abfrage der aktuellen Stimmen wird künstlich um 5 Sekunden verzögert. Wenn Sie die Webapp öffnen und eine Abstimmung abgeben, bevor der Status empfangen wird, ist in Kürze die korrekte Anzahl der Stimmen sichtbar, sobald die Abstimmung durchgeführt und die Aktualisierung empfangen wurde.
Schließlich kommt der verzögerte Zustand - und eine veraltete Stimmenzahl wird angezeigt.

Answer 1

Die saubere Lösung dieses Problems ist ein neues (not yet dokumentiert feature in Crossbar.io: event Retention

Diese Option Abonnenten mit einem einzigen beibehalten Ereignis vor dem ersten Strom Subskriptionsereignisservices bietet Die beibehaltene Veranstaltung ausgewählt.. . der Herausgeber Wenn der Verlag jedes Ereignis auswählt, dann diese Funktion bietet Ihnen den letzten veröffentlichten Zustand

Es ist ein Beispiel dafür an https://github.com/crossbario/autobahn-python/tree/master/examples/twisted/wamp/pubsub/retained

(Nicht sicher Unterstützung in Bibliotheken mit Ausnahme der Autobahn |. P ython.)

Ansonsten: Ihr Muster mit Abonnement vor dem Anruf sinnvoll, sowie mit Zeitstempeln.