több szál kezelése

Fórumok

Egy elvi kérdésem lenne. Lenne egy alkalmazás, ami ciklusonként felovas pl egy adatfile-t vagy kiolvas adatbázis adatokat. A kapott infó alapján kialakít tcp kapcsolatokat, ezeket kezeli, dolgozik bennük, majd ha a felolvasott infó alapján már nem kell, akkor leboltja, vagy ha kell újat azt felépíti.
Ha lebomlik vagy valami más hiba van akkor akkor fix folyamatot követ végig, ez talán most nem lényeg.
Nem tudom igazán merre induljak el. Csináljak egy nagy ciklusra épülő kódot, vagy az egyes tcp kapcsolatokat bizzam egy egy thread-re, amit a szülö kezel, mivel mind ugyan azt a dolgot csinálja. Vagy van valami jó javaslatotok, tényleg csak elvi szinten.
Lehet C vagy C++ is, amelyik jobban simul a feladathoz szerintetek és egyszerűbb a megvalósítása.

Köszi

Hozzászólások

Szerintem nem hatékony minden kapcsolatra egy szál, bár sok helyen láttam már.
Mindenképpen C++.
Én csinálnék egy threadpoolt, fix mennyiségű szállal, azoknak csak átadnám a kezelendő adatot.
De figyelj oda mert a lassú a tcp kapcsolat felépítése lesz, nem a szálak száma.
Mégegy, figyelj oda,hány magos procid van, mert nem érdemes túl sok szálat indítani, mindig van egy optimum

Én úgy csináltam, hogy volt egy elképzelésem (eredetileg minden kapcsolat egy szál), implementáltam, lemértem a teljesítményt, és utána módosítottam. Igy 4 iterációval eljutottam a nekem optimális megoldásig. A Threadpool teszteltem, írtam egy sajátot is, de nem volt teljesítménybarát

Gondolkoztal esetleg Java-n? Csak mert a threadpoolok, a threadek, es TCP kapcsolatok felepitese mind benne vannak az alap API-ban, gyakorlatilag csak a worker reszt kellene megirnod.

--
The Net is indeed vast and infinite...
http://gablog.eu

Nem is a programnyelv a lenyeges, hanem hogy min van a hangsuly...:
- mennyire bonyolult az "egy socketen valo kommunikacio", azaz mennyire kell sok adatot megmozgatnia (a programon belul), mennyire sajat fejlesztes az a kod, ami lekezeli az egy adott klienssel folytatott kommunikaciot, stb.
- mennyi a protokoll ill. az egesz vegleges rendszer latency-je, mennyi a kapcsolat atlagos hossza, stb.
- az egyik kliens altal lezavart kommunikacio mennyire szol bele egy masik klienssel valo kommunikacioba
- ...

Azaz:
* ha bonyolult a per-kliens protokoll, nem (nagyon) szolnak bele egymasba a kliensek, relative hosszu egy socket elettartama, a latency vagy egyes kliens altal kuldott adat feldolgozasa relative sokaig tart, akkor mindenkeppen thread.
* ha forditva: egyszeru per-kliens kommunikacio, sok a kliensek kozotti athatas, rovid elettartam, az adatot gyorsan fol lehet dolgozni, akkor meg szinte egyertelmu"en "egy nagy ciklus" + async multiplex.

Atmeneti helyzetekben meg lehet merlegelni, mi a nagyobb szopas ;)

Kedves Kollégák!

A topic-indítóéhoz hasonló kérdéssel fordulok Hozzátok.
Szeretnék írni C-ben egy egyszerű szervert, amihez egy időben akár több tíz kliens is csatlakozhat. A TCP kapcsolat felépítésekor minden kliens azonosítja magát. A kliensek által küldött adatokat az adott klienshez tartozó fájlba kell kiírni.
Szálakra nem szívesen szedném szét, mert mondjuk 60 szál brutálnak tűnik (a kapcsolatok akár több hétig is élhetnek).

Mit javasoltok, hogyan kezeljem le a kapcsolatokat?
(Még) nem erősségem a socket programozás.