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
- 2051 megtekintés
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
- A hozzászóláshoz be kell jelentkezni
egy tcp-re gondoltam 1 szálat, de olyan sok nem lesz max kb 10 egyidejű, viszont ezek talán napokig is aktívnak kell hogy maradjanak.
Én is egy threadpoolt kialakításásra gondoltam első körben.
Köszi
- A hozzászóláshoz be kell jelentkezni
É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
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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 ;)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Ezt a libet használd és akár 10 ezer párhuzamos kapcsolatot is kiszolgálhatsz 1 szálon nagyon egyszerűen.
- A hozzászóláshoz be kell jelentkezni
Köszönöm. Meg is nézem.
Úgy sejtem, a select(2) körül kell keresgélnem.
- A hozzászóláshoz be kell jelentkezni
Régen select-tel oldották ezt meg, de ma már minden oprendszeren vannak sokkal hatékonyabb módszerek.
Ezek (epoll, kqueue, stb) persze különböznek egymástól.
A libevent egy egyszerűen kezelhető, egységes, ezért hordozható felületet ad ezekhez.
- A hozzászóláshoz be kell jelentkezni
És sokan, akik a libeventet ismerik, nem ismerik ezt:
http://software.schmorp.de/pkg/libev.html
- A hozzászóláshoz be kell jelentkezni
Nem rossz. Nekem libevent bevált. Tökéletesen stabil és rettentő gyors.
Neked volt valami kifejezett előnye libev-nek, ha csak socket szervernek kellett használni?
- A hozzászóláshoz be kell jelentkezni
A natív API-ja kicsit más, a benchmarkok szerint gyorsabb, amúgy semmi.
- A hozzászóláshoz be kell jelentkezni