<div dir="ltr">Zdravim,<br><br>kdyz uz jsme u tech navrhovych vzoru a best practices, mam taky jednu lahudku, kterou v techto dnech resim. A protoze se mi vsechny me napady zdaji prilis komplikovane,obracim se na vas, jestli me treba nenakopnete nejakym smerem. Anebo si jen utridim myslenky...<br>
<br>Delam program, ktery bude (silne zjednodusene) delat neustale dve veci dokola:<br><br>a) Pripojit se socketem k serverum<br>b) Poslat HTTP request a stahnout data<br><br>Jsou zde tri problemy:<br>*) Tech serveru je cca 1000 a requesty by mely byt vyslany v co nejmensim casovem rozestupu (idealne soucasne nebo s rozestupem par sekund).<br>
<br>*) Nejedna se o klasicke socketove spojeni, to navazovani kazdeho spojeni ma mnoho stavu (cca 5), ktere nejsou v pevne definovanem sledu. Tj. nekdy se spojeni zdari, nekdy jsou problemy, takze dochazi k vetveni (napriklad 3x pokus o pripojeni, nasledne ignorace spojeni v tomto cyklu + zapis do binlogu, ze se spojeni nepovedlo, pro dalsi analyzu).<br>
<br>*) Navic knihovna realizujici spojeni je programovana asynchronne (coz muze byt vyhoda, ale take komplikace) a informace o stavu mi jsou vraceny pomoci callbackovych funkci, ktere ale bezi v prostredi vlakna te knihovny. Takze ikdyz bych se rad vyhnul thread programmingu, v pripade zpracovavani tech callbacku musim vyuzit nejake zamky apod.<br>
<br>Vidim zde nasledujici varianty reseni:<br>1) Jednovlaknovy proces, postupne vytvori spojeni (tj. synchronni bridge te asynchronni knihovny) a postupne posle pozadavky. Vyhody: Velmi jednuduche ba trivialni. Nevyhody: Zpracovani jednoho pozadavku cca 5-10 sekund,tj. casovy rozestup od prvniho a posledniho requestu 1 - 3 hodiny. Neprijatelne.<br>
<br>2) Kazdy server bude mit sve vlakno, tj. 1000x jednoducha operace spojeni + requestu. Pred samotnym vyslanim requestu by vlakna cekaly na nejaky spolecny signal, kvuli synchronizaci. Vyhody: Jednoduche, requesty okamzite (jedine omezeni je cca 100Mbit linka serveru, tj. ocekavam vyrizeni behem max 30 sekund). Nevyhody: Nemam tuseni, jak se bude tvarit proces s 1000 vlakny, co to udela se serverem.Navic se bojim managementu vlaken, deadlocku apod....Navic ciste dlouhodobe muze pocet serveru/vlaken rust do nekonecna.<br>
<br>3) Zcela asynchronni proces. Velmi elegantni reseni jednim vlaknem. Vytvareni okruhu a samotne requesty by kvuli jednoduchosti byly separatni kroky (tj. metoda startujici stahovani by se spoustela az po vytvoreni vsech spojeni, resp. po dostatecnem poctu odmitnuti nekterych spojeni). Problem je,ze v obou krocich se jedna o stavove stroje s mnoha stavy. S riziky asynchronnich procesu a s navrhem takovych uloh nemam zadne zkusenosti. Tj. v jakych datovych strukturach udrzovat jake informace o jednotlivych requestech apod.<br>
<br>A vas se ptam - prehlednul jsem neco, co by cely proces zjednodusilo, doporucili byste mi neco jineho nebo mate zkusenosti s navrhem asynchronnich procesu?<br><br>Diky,<br>Marek<br></div>