reklama

Uváznutí v Aktor systému

Re:Uváznutí v Aktor systému
« Odpověď #45 kdy: 21. 10. 2019, 22:22:10 »
Jak to myslíš víc jak jednoho klienta?

Ten systém by mohl třeba umožňovat to, aby se - pokud jde např. o výpočetní úlohy - do systému registroval nějaký další aktor, který bude odebírat zprávy „výpočet hotov“ a bude z výsledku výpočtu dělat třeba grafy, statistiky nebo notifikace. Takový aktor by šel zaregistrovat ad-hoc, tj. by nebylo potřeba ostatní aktory pro tento případ upravovat, stačilo by napsat toho nového aktora a zaregistrovat ho, klidně za běhu systému. Nakonec by to mohlo vést na distribuovaný systém přes více počítačů.

IMHO by stačilo použít existující aktorový systém (akka ...) - psát vlastní má smysl pro výukové potřeby nebo pro speciální případy (běh na speciálním hardware...).

reklama


Re:Uváznutí v Aktor systému
« Odpověď #46 kdy: 21. 10. 2019, 22:24:13 »
psát vlastní má smysl pro výukové potřeby
Což je myslím přesně to, o co BoneFlutovi jde - a je mu to ke cti :)

BoneFlute

  • *****
  • 1 280
    • Zobrazit profil
Re:Uváznutí v Aktor systému
« Odpověď #47 kdy: 22. 10. 2019, 01:55:04 »
Já to mám vymyšlený tak, že runtime vyzvedává zprávy a ty potom prochází “volá” aktor s tou zprávou.

Můžeš to okomentovat v čem je to řešení výhodnější/zajímavější.
Při téhle implementaci pravděpodobně narazíš, protože ti tam chybí právě ta možnost, aby si sám aktor určil, kterou zprávu chce zpracovat. Jestli teda dobře rozumím tomu, jak to myslíš.

Jak to myslíš víc jak jednoho klienta?
Actor poskytuje nějakou službu a ostatní actory tu službu využívají - v té chvíli se jim dá říkat "klient", protože to de facto není v tu chvíli nic jinýho než starej dobrej klient-server.

Pokud ten protokol je stavový (tj. jeden akt/session/... se skládá z víc než jedné zprávy a mezi zprávama je potřeba si pamatovat stav), tak se to může (ale nemusí) implementovat tak, že se vyřídí jeden "akt" (několik zpráv) v celku a až pak se jde na druhej. Jenže pokud je víc klientů, tak se ty zprávy můžou prolínat - a ty si potřebuješ vybrat tu, kterou teď zrovna chceš zpracovat.

Příklad:
Máš protokol:
A -- hi --> B
A <-- welcome -- B
A -- bye --> B
[konec]

Aktora B chceš z nějakýho důvodu napsat tak, aby tohle celý zpracoval naráz (nepřeskakoval mezi klienty). Zprávy mu ale můžou přijít pomíchaný:
1. A -- hi --> B
2. A <-- welcome -- B
3. C -- hi --> B
4. A -- bye --> B

- potřebuješ nutně možnost vybrat si selektivně zprávu 4. a teprve potom 3.

Možná se ti zdá, že tohle dělat nemusíš a dá se to obejít (třeba spawnutím spešl aktoru pro každou session). Stoprocentně ale narazíš na situaci, kdy to budeš potřebovat. Minimálně pro tu prioritizaci, která se (AFAIK) jinak než selektivním vybíráním zpráv řešit nedá.

U tohoto se prosím ještě zastavme. Já bych to řešil právě tou session. Přijde mi to takové intuitivnější. Aktor A + Zpráva + Session komunikace (kterou dodá obsluha). Tedy to, zda je ta zpráva od aktora B, nebo C(, nebo dokonce B jiná session) řeší runtime, a nikoliv vlastní Aktor. Aktor je jen a pouze vlastní logika. Takto si to představuju. V čem bych mohl narazit?

Proč bych měl chtít, pokud jsem tě pochopil dobře, aby aktor nepřeskakoval mezi klienty?

Já bych si přestavoval, že ten aktor je do značné míry bezestavový. Respektive ten stav je uložen mimo, ve službách a v session. Ale samozřejmě si rád vyslechnu proč je to blbej nápad :-)

BoneFlute

  • *****
  • 1 280
    • Zobrazit profil
Re:Uváznutí v Aktor systému
« Odpověď #48 kdy: 22. 10. 2019, 02:02:51 »
Jak to myslíš víc jak jednoho klienta?

Ten systém by mohl třeba umožňovat to, aby se - pokud jde např. o výpočetní úlohy - do systému registroval nějaký další aktor, který bude odebírat zprávy „výpočet hotov“ a bude z výsledku výpočtu dělat třeba grafy, statistiky nebo notifikace. Takový aktor by šel zaregistrovat ad-hoc, tj. by nebylo potřeba ostatní aktory pro tento případ upravovat, stačilo by napsat toho nového aktora a zaregistrovat ho, klidně za běhu systému. Nakonec by to mohlo vést na distribuovaný systém přes více počítačů.

Ano, tak nějak si to představuju. Zřejmě jsem jenom nepochopil jak to myslí s těmi klienty. Pochopitelně že ti aktoři jsou prostě v roli klient server.

To co popisuješ by ale vyžadovalo, aby ty data byly někde uschovány. Takže nějaký aktor "databázista/knihovník" který výsledky bude uchovávat. Nebo se k tomu poslednímu aktoru přihlásit jako subscriber, aby mi taky poslal výsledek. Ano, tyto vlastnosti a důsledky si uvědomuji.

Re:Uváznutí v Aktor systému
« Odpověď #49 kdy: 22. 10. 2019, 08:53:44 »
U tohoto se prosím ještě zastavme. Já bych to řešil právě tou session. Přijde mi to takové intuitivnější. Aktor A + Zpráva + Session komunikace (kterou dodá obsluha). Tedy to, zda je ta zpráva od aktora B, nebo C(, nebo dokonce B jiná session) řeší runtime, a nikoliv vlastní Aktor. Aktor je jen a pouze vlastní logika. Takto si to představuju. V čem bych mohl narazit?

Proč bych měl chtít, pokud jsem tě pochopil dobře, aby aktor nepřeskakoval mezi klienty?

Já bych si přestavoval, že ten aktor je do značné míry bezestavový. Respektive ten stav je uložen mimo, ve službách a v session. Ale samozřejmě si rád vyslechnu proč je to blbej nápad :-)
Takže vlastně tvoje představa je spíš bližší HTTP než aktorovému systému ala CSP :) Jako proč ne? Klidně to tak udělat můžeš, ale pravděpodobně si tím na sebe uvalíš omezení, která ti pak neumožní dělat některé věci, které se v opravdovém aktorovém systému dělat dají, nebo budou zbytečně složité. Pravděpodobně se dostaneš k "něčemu podobnýmu RESTu" a hlavní otázka pak je, proč to vůbec dělat a nepoužít REST :)

Pokud bych měl říct konkrétněji, co mi přijde jako nevýhody takového řešení: pokud má runtime jakýmkoli způsobem manipulovat s komunikačními akty (např. je zhlukovat do těch sessions), tak:
1. musí té komunikaci rozumět (minimálně musí umět poznat začátek a konec)
2. buď teda budeš muset mít natvrdo jeden "metaprotokol" (např. zprávy "BEGIN" a "END" budou muset být součástí každé komunikace
3. nebo budeš muset nějak do runtimu nahrát popis protokolu
4. připravíš se o některé možnosti dynamického dispatche zpráv - u jednotlivých izolovaných zpráv můžeš třeba jednu konkrétní zprávu přehodit na jinýho aktora. Tady to nebudeš moct udělat, protože co by se pak dělo se session?

Už tohle je imho úplně zbytečný opruz, který tě bude stát jenom práci navíc, bude tě svazovat a nevidím žádný přínos, který by přinášel oproti klasice (neříkám, že neexistuje, jenom, že si ho teď neumím představit).

V klasickém aktorovém systému se můžeš ty, jako autor aktoru, rozhodnout, jestli v tu kterou chvíli komunikuje stylem "session" nebo stylem "ad hoc zpráva".  Prostě kód napíšeš tak nebo tak. Pokud budeš muset použít session, budeš mít úplně zbytečnou režii u komunikací, které session nijak nevyužijí (např. máš aktor, který čte stav tlačítka a když dojde ke změně stavu, pošle o tom zprávu jinému aktoru - to je bezestavová, jednozprávová komunikace, session tam k ničemu není).

Bez session:

A->B: switch=on
...
A->B: switch=off

S vynucenou session:

A->B: BEGIN
A->B: switch=on
A->B: END

+ režie toho, že někdo někde (úplně zbytečně) drží informace o té sešně.

Nevím, prostě se mi to intuitivně nezdá. Není to imho cesta správným směrem. Pokud chceš pochopit, na co jsou aktory dobré, drž se prostě CSP nebo toho, jak to má Erlang.

reklama


Re:Uváznutí v Aktor systému
« Odpověď #50 kdy: 22. 10. 2019, 09:24:40 »
Ten systém by mohl třeba umožňovat to, aby se - pokud jde např. o výpočetní úlohy - do systému registroval nějaký další aktor, který bude odebírat zprávy „výpočet hotov“ a bude z výsledku výpočtu dělat třeba grafy, statistiky nebo notifikace. Takový aktor by šel zaregistrovat ad-hoc, tj. by nebylo potřeba ostatní aktory pro tento případ upravovat, stačilo by napsat toho nového aktora a zaregistrovat ho, klidně za běhu systému. Nakonec by to mohlo vést na distribuovaný systém přes více počítačů.

Ano, tak nějak si to představuju. Zřejmě jsem jenom nepochopil jak to myslí s těmi klienty. Pochopitelně že ti aktoři jsou prostě v roli klient server.

To co popisuješ by ale vyžadovalo, aby ty data byly někde uschovány. Takže nějaký aktor "databázista/knihovník" který výsledky bude uchovávat. Nebo se k tomu poslednímu aktoru přihlásit jako subscriber, aby mi taky poslal výsledek. Ano, tyto vlastnosti a důsledky si uvědomuji.

Ano, buď si musí ti aktoři předávat kompletní data (pak budou aktoři bezstavové funkce cca ve smyslu funkcionálního programování) anebo musí mít nějaké sdílené úložiště (např. databázi), tedy sdílený stav.

Pokud by roli databáze plnil aktor, tak by šlo v principu o implementaci té první varianty, tj. kompletní předání dat (data by protékala message-busem toho systému). Asi bychom raději  chtěli, aby tím nevznikla explicitní závislost na „databázovém“ aktoru, takže bychom chtěli, aby o sobě aktoři nevěděli a pouze se registrovali k odběru událostí. Takže by pak komunikace mohla probíhala stylem:

Citace
A->systém: máte někdo data xy?
systém->A: tady má někdo data xy

Oprávnění by se řešilo předáním autorizačního tokenu při dotazu na data nebo při registraci k odběru události „tady má někdo data xy“. Záleží samozřejmě, zda by aktor věděl, kdo mu zprávu zasílá a zda by pak odpovídal zpětně tazateli, nebo zda by odpověď vkládal na message-bus, tj. emitoval zprávu „tady má někdo data xy“. Druhá varianta je lepší, pokud se vyřeší oprávnění a třídění zpráv kvůli výkonu (aby ten systém nelehnul, protože bude každý reagovat na každého).

Já bych to řešil právě tou session. Přijde mi to takové intuitivnější. Aktor A + Zpráva + Session komunikace (kterou dodá obsluha). Tedy to, zda je ta zpráva od aktora B, nebo C(, nebo dokonce B jiná session) řeší runtime, a nikoliv vlastní Aktor. Aktor je jen a pouze vlastní logika. Takto si to představuju. V čem bych mohl narazit?

Session znamená připojit stav k původně nestavovému protokolu. Zde vidím rozpor s tím, že jinde říkáš, že mají být aktoři nestavoví. Osobně bych se na session vykašlal, do aktorové koncepce IMHO moc nezapadá.

Re:Uváznutí v Aktor systému
« Odpověď #51 kdy: 22. 10. 2019, 09:35:39 »
Ano, buď si musí ti aktoři předávat kompletní data (pak budou aktoři bezstavové funkce cca ve smyslu funkcionálního programování) anebo musí mít nějaké sdílené úložiště (např. databázi), tedy sdílený stav.
Drobná technická: v tomhle konkrétním případě žádné sdílené úložiště není potřeba, pokud aktor vykreslující grafy nebude nikdy požadovat historická data. Pokud bude jenom poslouchat přicházející data a z nich kreslit graf, tak potřebujeme držet jenom:
1. seznam aktorů, kteří data chtějí přijímat
2. buffer dat pro vykreslení grafu

První data si drží lokálně nějaký ten "distribuční" aktor, druhá data si drží lokálně grafovací aktor. Jsou potřeba jenom zprávy:
1. přihlašuji se k odběru
2. přibyl nový datapoint
3. odhlašuji se z odběru
a žádná sdílená data, žádná databáze.

Re:Uváznutí v Aktor systému
« Odpověď #52 kdy: 22. 10. 2019, 09:41:13 »
Session znamená připojit stav k původně nestavovému protokolu. Zde vidím rozpor s tím, že jinde říkáš, že mají být aktoři nestavoví. Osobně bych se na session vykašlal, do aktorové koncepce IMHO moc nezapadá.
Myslím, že to BoneFlute řekl správně: pokud se všechna potřebná data drží v session, může být aktor nestavový.

Tenhle přístup se někdy používá v HTTP autorizaci. Jsou dvě cesty:
1. stavový aktor: klientům přiděluju IDčka a držím si tabulku "tohle ID má přístup do tehdy a tehdy"
2. nestavový aktor: do session uložím "přístup povolen do tehdy" a sám nemusím žádný stav držet (session ale musí být udělaná tak, aby s ní klient nemohl manipulovat - např. zašifrovaná serverem). Klient a server (aktor) si pak data session posílají tam a zpátky s každým requestem.


Re:Uváznutí v Aktor systému
« Odpověď #53 kdy: 22. 10. 2019, 14:32:44 »
Ano, buď si musí ti aktoři předávat kompletní data (pak budou aktoři bezstavové funkce cca ve smyslu funkcionálního programování) anebo musí mít nějaké sdílené úložiště (např. databázi), tedy sdílený stav.
Drobná technická: v tomhle konkrétním případě žádné sdílené úložiště není potřeba, pokud aktor vykreslující grafy nebude nikdy požadovat historická data.

Jasně, podobně i ten logovací aktor - taky jen zapíše a zapomene.

Re:Uváznutí v Aktor systému
« Odpověď #54 kdy: 22. 10. 2019, 14:44:56 »
Session znamená připojit stav k původně nestavovému protokolu. Zde vidím rozpor s tím, že jinde říkáš, že mají být aktoři nestavoví. Osobně bych se na session vykašlal, do aktorové koncepce IMHO moc nezapadá.
Myslím, že to BoneFlute řekl správně: pokud se všechna potřebná data drží v session, může být aktor nestavový.

A v případě aktorů by do té session přistupoval aktor nebo systém? Session může sloužit pro uložení ledasčeho, nejen autorizace. Ten storage na data bys řešil jak?

Re:Uváznutí v Aktor systému
« Odpověď #55 kdy: 22. 10. 2019, 15:49:52 »
A v případě aktorů by do té session přistupoval aktor nebo systém? Session může sloužit pro uložení ledasčeho, nejen autorizace. Ten storage na data bys řešil jak?
Já bych hlavně session v tomhle smyslu nepoužil. To byl BoneFlutuv napad.

Re:Uváznutí v Aktor systému
« Odpověď #56 kdy: 22. 10. 2019, 17:42:24 »
A v případě aktorů by do té session přistupoval aktor nebo systém? Session může sloužit pro uložení ledasčeho, nejen autorizace. Ten storage na data bys řešil jak?
Já bych hlavně session v tomhle smyslu nepoužil. To byl BoneFlutuv napad.

OK. I tak mě ale zajímá, jak bys řešil přístup k persistentnímu storage. A pak jestli bys nechal aktory komunikovat pomocí sběrnice, kde se mohou za běhu porůznu registrovat k odběru událostí jednotliví aktoři. Předpokládejme, že je cílem nějaký výpočetní cluster s probíhajícími výpočty, které na sobě porůznu závisí (nějaká simulace třeba).

Re:Uváznutí v Aktor systému
« Odpověď #57 kdy: 22. 10. 2019, 19:16:01 »
OK. I tak mě ale zajímá, jak bys řešil přístup k persistentnímu storage. A pak jestli bys nechal aktory komunikovat pomocí sběrnice, kde se mohou za běhu porůznu registrovat k odběru událostí jednotliví aktoři. Předpokládejme, že je cílem nějaký výpočetní cluster s probíhajícími výpočty, které na sobě porůznu závisí (nějaká simulace třeba).
Tezko rict, to je asi moc specificka otazka, ktera by zalezela na detailnich pozadavcich na ten system.

Obecne bych asi spis moc nepouzival slovo "sbernice", to do aktoroveho sveta imho moc nesedi. Pokud bych mel vypocetni cluster s nejakymi workery, kteri se hlasi o zadani vypoctu, tak bych mel asi nejaky "registr" aktor, kteremu by se worker ohlasil, ze chce praci a registr by workerum bud primo praci rozdeloval, nebo by jenom udrzoval jejich seznam a praci by rozdeloval zase jiny aktor. Zalezi hlavne na mnozstvi tech uloh - jestli by registr byl nebo nebyl uzky hrdlo...

Zavislosti se zase daji resit ruzne. Spawnovani novych actoru je typicky levne, takze casto se ruzne zavislosti daji resit treba tak, ze se spawne nekolik actoru a nekteri z nich proste cekaji na to, az se dokonci ulohy, na kterych jejich uloha zavisi. K tomuhle je ale dobry mit ten system "linku" - aby se dal cely ten "strom" actoru shodit naraz, pokud dojde k nejake chybe.

Persistentni storage je velky tema, silne implementacne zavisly. Jako rule of thumb bych se hlavne snazil dobre promyslet, jestli opravdu persistenci potrebuju. Mam zkusenost, ze dost casto se ukaze, ze vlastne vubec potreba neni.

Dam takovej pripad jedne veci, na ktere delam zrovna ted: jsou nejake streamy dat a nekdo nekdy v historii vymyslel, ze ty streamy budou oznacene nevyznamovymi IDcky (napr. "BFLM"). System funguje tak, ze prijdou data ze zarizeni, ktery ma ID treba "A", a v ramci toho zarizeni ma ten stream ID napr. "TEMP1" (je to teplota na prvnim cidlu). No a kdyz teda to dato prijde, tak se v databazi vyhleda mapovani (A, TEMP1) => BFLM a dal ten stream putuje pod timhle IDckem.

Zasadni otazka je, k cemu je vlastne to mapovani dobry. Co kdybych ten stream oznacil IDckem "A-TEMP1"? Prisel bych o neco? A pritom bych krasne odstranil perzistenci, databazi, pripadne i uplne stavovost...

To jenom takova drobna stupidni ilustrace...
« Poslední změna: 22. 10. 2019, 19:18:39 od Mirek Prýmek »

BoneFlute

  • *****
  • 1 280
    • Zobrazit profil
Re:Uváznutí v Aktor systému
« Odpověď #58 kdy: 23. 10. 2019, 02:06:35 »
A v případě aktorů by do té session přistupoval aktor nebo systém? Session může sloužit pro uložení ledasčeho, nejen autorizace. Ten storage na data bys řešil jak?
Já bych hlavně session v tomhle smyslu nepoužil. To byl BoneFlutuv napad.

Možná je zavádějící výraz Session. Co třeba Stav? Vlákno konverzace?

Ten Session/Stav byl myšlen, že mezi aktorem A a B vznikne komunikace, která pokračuje. Aktor si tam může uložit co chce, a pokud bude pokračovat ve stejném vláknu konverzace, tak to tam zase najde. Neslouží to k předání dat někomu jinému. Jakmile konverzaci ukončí, tak tato data zaniknou. Pokud začne novou konverzaci, tak tam také nejsou.

Představoval jsem si, že by bylo vhodnější, když by toto řešil systémově runtime, a nikoliv když by si to každý aktor dělal po svém. Ale promyslím si tvé výhrady.

Re:Uváznutí v Aktor systému
« Odpověď #59 kdy: 23. 10. 2019, 11:20:13 »
Představoval jsem si, že by bylo vhodnější, když by toto řešil systémově runtime, a nikoliv když by si to každý aktor dělal po svém. Ale promyslím si tvé výhrady.
Proč myslíš, že je to vhodnější, a co očekáváš, že tím získáš? Actor sám má nejlepší informace o tom, v jaké fázi komunikace je, a taky vytváří ty data. Pokud použiješ tu session, tak oboje budeš muset předat někam jinam a při každém requestu si to zase brát zpátky. Není lepší si to prostě nechat u sebe? :)

Očekáváš, že když to budeš mít v runtimu na jednom místě, tak se ti to bude líp persistovat? Nebo?

 

reklama