Dotaz: Sockets & multithreading C++

[Filgron]

Zdravím zdejší guru,

 

v nedávné době jsem se začal zabývat a zajímat o používání socketů v C++ a tvorbou jednoduchých client/server aplikací. Postoupil jsem k problému, kdy chci řešit modelovou situaci:

Existuje server, který periodicky načítá informace z blíže nespecifikovaného zdroje a ukládá si je do mezipaměti (pro zjednodušení řekněme soubor), tento server bude ,,poslouchat" na síti a bude obsluhovat klienty (klient se buďto pouze připojí, zažádá o informace z mezipaměti a hned se odpojí, nebo zůstane na kafe a bude si se serverem vyměňovat lichotky delší dobu). Klientů může být v jedné chvíli připojeno více, ale taky může být jen jeden a nebo o kafe v tuto chvíli nemá zájem nikdo.

Zvažují vhodnou implementaci, zda-li to pojat jako více-vláknovou aplikaci, kdy jedno vlákno se stará o ukládání dat do mezipaměti, další o správu socketů s tím, že pro každého klienta by existovalo zvláštní vlákno, které by mu čaj naservírovalo.

Druhou možností, co mne napadá je využití neblokovaného režimu socketů a selectu.

 

Rád bych se Vás zeptal, který způsob je vhodnější, popř. pokud by Vás napadla jakákoliv jiná možnost, byl bych za ni velice rád)

 

Ještě maličkost, ohledně více-vláknových aplikací bych Vás chtěl poprosit o radu, jakou knihovnu při nich eventuálně použít s tím, aby případná migrace mezi operačními systémy byla co nejméně bolestná (myšlen Tux a Win). Předem děkuju za Váš čas a případné kopance)

Odpovědi

[Messa]

Pokud to má mít vysoký výkon nebo to má obsluhovat mnoho najednou připojených klientů, pak je nejlepším řešením epoll, select apod. Jinak si to můžeš naprogramovat, jak chceš :)

Řešení pomocí vláken - tedy jedno vlákno na jednoho připojeného klienta - je řekl bych oblíbené, protože komunikace s klientem se pak snadno programuje. S vlákny mohou být problémy - žerou prostředky (paměť, také context switch není nejlevnější), špatně se ladí, mohou vznikat opravdu ošklivé chyby při špatné synchronizaci vláken. Tisíce vláken vedle sebe asi není ideální stav.

Řešení pomocí selectu, epollu apod. je výkonnější, ale implementace takového serveru je o něco těžší.

Je možná i kombinace - spojení, na kterých se zrovna nic neděje, mohou odpočívat v selectu/epollu, když ale něco přijde, může se o ně začít starat pro ně vyhrazené vlákno.

Selectování/epollování rozdělit do více procesů, aby nebylo příliš spojení na jeden proces - počet otevřených deskriptorů je defaultně omezen tuším na 1024, dá se to zvýšit, ale AFAIK zase ne o moc.

Jenom bych chtěl upozornit, že při selectování nemusejí být sokety v neblokujícím režimu :) Ten je zcela nutně potřeba snad až u edge-triggered epollu.

Jestli je to vážně míněný projekt, je dobré přemýšlet i o bezpečnosti - o tom, jakým způsobem by útočník mohl server znepřístupnit nebo shodit, např. příliš velkým počtem spojení s napůl odeslaným požadavkem.

[Michal Kubeček]

Pokud to má mít vysoký výkon nebo to má obsluhovat mnoho najednou připojených klientů, pak je nejlepším řešením epoll, select apod.

Jen za předpokladu, že vygenerování odpovědi je velmi rychlé a nenáročné. Jinak je tato varianta dost nešťastná.

Řešení pomocí vláken - tedy jedno vlákno na jednoho připojeného klienta - je řekl bych oblíbené, protože komunikace s klientem se pak snadno programuje.

Spíš bych řekl, že použití vláken - aspoň u linuxových aplikací - moc populární není a stále výrazně převažuje používání samostatných procesů. Kromě již zmíněného k tomu asi přispěla i skutečnost, že vlastně až s jádry 2.6 (OK, u Red Hatu o chloupek dřív) přišla rozumně použitelná implementace POSIX threads.

[pht]

Vlákna. Jelikož máme více jádrové procesory, tak to do jistého počtu vláken poběží rychleji, než kdyby se obsluha požadavků dělala sériově. Pokud bude počet vláken najednou extrémně vysoký, můžete začít vlákna poolovat.

jakou knihovnu při nich eventuálně použít s tím, aby případná migrace mezi operačními systémy byla co nejméně bolestná

Boost.

[dad]

Threads are evil. Avoid them. (D.Hipp, sqlite)

http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf

[Sten]

Doporučuji si nastudovat řešení nginxu, lépe už to nejde (je to kombinace vláken a epollu)

Boost je multiplatformní. Umí thready (Boost::Thread) i sockety (Boost::ASIO).

[Filgron]

Děkuji všem za názory/připomínky, po lehkém zvážení jsem se rozhodl započít vývoj v knihovně Qt (kterou aspoň částečně již znám), výhodu vidím v tom, že víceméně na jakoukoliv funkcionalitu (např. parsování XML) existují knihovny a také samozřejmě využití signálů a slotů + víceméně bezproblémová portace na Win.

Prozatimní poupravený návrh počítá s tím, že bude existovat jedno vlákno (které bude načítat informace z externího zdroje do mezipaměti v loopu, signálem je bude zasílat hlavní třídě, popř. bude od hlavní třídy očekávat instrukce (čtené slotem a přidávané do fronty, která se provede při každém průchodu cyklem)

Ohledně připojování klientů, zatím stále váhám, jestli použít QThreadPool, kde by každý klient měl vlastní vlákno (neočekává se velký počet klientů , max 5 současně), nebo použít select (ač u něj nevím, jak v Qt).

K další otázce, projekt je zatím myšlen pouze pro ,,studijní" účely, samozřejmě při ,,reálném" nasazení by jej bylo třeba zabezpečit.