Nagyszámú bejövő kapcsolat fenntartása (C daemon / fork / pthread)
Sziasztok!
Adott néhány rendszer mikrovezérlőkkel megvalósított hálózati kommunikációval.
Van ennek egy szerveroldali (Linux) daemonja, ami várja az eszközöket, ismeri a protokollt, titkosítást, és levezényli a kapcsolatot, majd bontja azt és x idő elteltével újrakezdődik az adatcsere.
Maga a kiszolgáló alkalmazás nem különösebben nagy méretű (bőven 100KB alatti). Ez az egyes kapcsolódások során forkolja magát, vár további kapcsolódásokra, és a felépült kapcsolaton vezényli a szükséges adatcserét.
Jelen esetben nincs szükség gyorsabb reakcióidőre, mint amit ez a rendszer tud.
Kérdésem, hogy milyen lehetséges problémákba futnék bele, ha olyan rendszert szeretnék létrehozni, ahol az egyes terminálok folyamatos kapcsolatot tartanak fenn (időnként életjelet küldve), és ezen a kapcsolaton szeretnék minél inkább real-time (max. néhány másodperces csúszással) adatokat átküldeni.
- Jelent-e problémát a sok forkolt process bizonyos egyidejűleg futó kommunikáció felett (fork miatti többletmemória-igényt nem számítva)?
- Van olyan szempont, ami miatt ellenjavallt folyamatosan fenntartani a kapcsolatokat?
Elvileg alapesetben socketenként 128 egyidejű kapcsolatot kezel a kernel, ez szükség esetén növelhető.
- Érdemes-e elgondolkozni inkább thread-ek használatán?
Maximális process-ek száma alapértelmezetten 32768
Egyáltalán nyernék valamit threadekkel, vagy jórészt csak annyit, hogy egy esetleges szoftverhiba felborítja az összes kliensem futó kapcsolatát? :)
Ha elmennék ebbe az irányba (folyamatos kapcsolatok), és továbbra is fork-olnám a klienseket, azzal elkövetnék kifogásolható "bűnt" vagy "szépséghibát"?
Szeretném a véleményeteket kérni ezzel kapcsolatban.
Mindenki javaslatát előre is köszönöm.
- Tovább (Nagyszámú bejövő kapcsolat fenntartása (C daemon / fork / pthread))
- 4592 megtekintés