Event id vs timestamp¶

getNewEvents(event_last_id) - vrátí seznam událostí, které vznikly po výskytu události s identifikátorem event_last_id

problémy:¶

• nově připojený odběratel potřebuje, aby mu bylo přiděleno rozumné event_last_id (jinak bude stahovat ze serveru všechna hlášení od data spuštění serveru)
• klient se po výpadku může dostat do podobné situace, jako nově připojený klient
• klient (nově připojený nebo po výpadku) neví, o jaký užitečný objem dat server požádat (logicky může chtít např. data za poslední týden, ale v současné podobě nelze z pohledu klienta ani serveru stanovi "týden")
• výše uvedené nelze rozumně řešit pomocí varianty getNewEvents(timestamp). Hodnota timestamp ukazuje čas detekce události, nikoliv čas uploadu na server (getNewEvents("-3 dny") ve skutečnosti nevrací všechny události, které server posbíral za poslední 3 dny, ale události, u nichž ostatní organizace tvrdí, že se staly během posledních 3 dnů)

řešení 1)¶

• klient si udržuje event_last_id, které získal v rámci posledního úspěšně přijatého hlášení
• klient (nově zapojený nebo po výpadku) poběží v omezeném řežimu:
  • po zapojení či výpadku je klient spuštěn jednorázově s parametrem -recovery (klient pak zavolá getNewEvents s parametrem -recovery).
  • server vrátí klientovi nejvyšší event_last_id, které je právě v DB uloženo.
  • klient tak "zapomene", že měl výpadek a pokračuje od aktuálního data (data zmeškaná v důsledku výpadku již klient neobdrží)
• výhoda: jednoznačná politika, klient vždy ví, která data obdržel a která ne (resp. neobdržel data za dobu výpadku)
• nevýhoda: zátěž serveru závisí na odpovědnosti klientů; zpětně nelze získat hlášení z minulosti

řešení 2)¶

• klient si udržuje event_last_id, které získal v rámci posledního úspěšně přijatého hlášení
• klient (nově zapojený nebo po výpadku) poběží stejně jako při běžném provozu:
  • klient zavolá getNewEvents(event_last_id).
  • server se pokusí odeslat klientovi všechna hlášení od event_last_id. Pokud však dávka překročí rozumnou hranici (treshold - nastaveno na serveru, např. 1000 hlášení), události nad treshold už odeslány nejsou
  • klient si updatne event_last_id a nadále pokračuje v běžném provozu
• výhoda: jednoduchá implementace, omezena zátěž serveru, v rozumné míře lze získat i události z minulosti
• nevýhoda: nutno s rostoucím rozsahem služby a s přihlédnutím k softwarovám a hardwarovým nárokům upravovat hodnotu tresholdu

řešení 3)¶

• na serveru bude navíc uložen v DB i čas příjetí hlášení serverem (timestamp_received)
• po výpadku (nebo po připojení) klient nemusí stahovat všechna data, o která přišel, ale může požádat o hlášení například týden stará
• výhoda: lze získávat i události z minulosti
• nevýhoda: do DB přibývá další atribut (navíc částečně redundantní - časová posloupnost je uložena i v event_id)