fork() a broadcasting vsem klientum

Zdravim,

Mam TCP server a pre kazde nove spojeni vytvaram novy proces - fork. Potrebuju mit ale moznost zasielania sprav vsem pripojenym klientum. Ako pri pouziti fork-u zistim pocet klientu a vsetky sockety na ktore mam boradcastovat ?

Napadlo ma reseni, kde si pred kazdym frok-om ulozim socket descriptor

if ((csd = accept(sd, (struct sockaddr *)&cliaddr, &clilen)) < 0) {
            if (errno == EINTR)
                continue;
            else
                printError(ERR_ACCEPT, sd);
}

bnd_sock.push_back(csd);
if ((pid = fork()) == 0) ....

alebo je lepsi pouzit select() ?

Odpovědi

Buď místo forkací architektury použiješ select, jak níže naznačuješ, a "broadcastování" budeš dělat jednoduššeji pomocí nějaké datové struktury, nebo, pokud chceš zůstat u forku, budeš muset zajistit způsob, jak předat zprávu dětskému procesu, aby on sám mohl tu zprávu odeslat klientovi. Na to je na webu plno tutorialů. Půjde to přes System V IPC, přes roury nebo sokety nebo i přes nějaké sdílené paměti.

Možná si myslíš, že při acceptu si uložíš fd klienta do nějakého vektoru (jak asi ukazuješ v tom kusu kódu), forkneš proces pro obsluhování toho spojení a pak zprávy určené všem klientům prostě napereš to těch file deksriptů, co sis zapamatoval. Jenže takhle jednoduše to nedělej, protože klient může mít pomalejší linku (nebo může nastat jedna z tisíce dalších náhodných situací), obsluhovací podproces může mít právě rozposílaný jeden příkaz, a doprostřed toho bys poslal tu "broadcastovou" zprávu - tím bys mohl narušit protokol ("rozbít" spojení). Muselo by tam být přinejmenším nějaké zamykání, ale to by mohlo být bezpečnostní riziko (server by mohl zamrznout, třeba když si nějaký klient nechá poslat schválně jen půl zprávy).

Kromě posílání zpráv podprocesům budou na webu určitě i ukázky nějakých jednoduchých irc-like chatů, řešících v podstatě kompletně tvůj problém. Dává se to ve školách jako domácí/samostatné úkoly.

Jak pise kolega, pri forkovani vznikne uplne novy proces, ktery nema s rodicem prilis mnoho spolecneho, kompletne oddeleny pametovy prostor, sance samozdrejme je s nim komunikovat jsou, jiz zde zminovany IPC.

Sdilena pamet mezi vice procesy patri taky do IPC, standartne se IPC deli na tyto kategorie.

- zpravy - doruceni

- synchronizace (tusim ze do toho spadaji veci kolem race condition semafory[mutexy atd])

- sdilena pamet

- vzdalene volani procedu (RPC)

O tom, ze se IPC pouziva vas muze presvedcit napr. utilitka ipcs, ukazuje vyuziti IPC mechanismu v systemu.

------ Segmenty sdílené paměti --------
klíč     shmid      vlastník práva     bajty      nattch     stav
0x0056a4d5 25362433       660        384        3
0x0056a4d6 40304642       660        131072     2
0x00000000 589827         777        393216     3          cíl
0x00000000 1114116         644        110592     3          cíl
0x00000000 1310725        600        393216     2          cíl
0x00000000 1441798        600        393216     2          cíl
0x00000000 5210119        600        393216     2          cíl
0x00000000 5242888        600        393216     2          cíl
0x00000000 47218700      776        1382400    0
0x00000000 47251469      776        1382400    0
0x00000000 47284238      776        1382400    0
0x00000000 47317007      776        1382400    0
0x00000000 47349776       776        1382400    0
0x00000000 47382545      776        1382400    0
0x00000000 47415314      776        1382400    0
0x00000000 47448083      776        1382400    0

------ Pole semaforů --------
klíč     semid      vlastník práva     nsems
0x0056a4d5 360450         660        1

------ Fronty zpráv --------
klíč     msqid      vlastník práva     užité bajty zprávy

Vlastnik jsem zamerne smazal.

Select neni vubec spatny napad podle me, taky je zde moznost misto fork to predelat do vlaken, vlakna natrpi nevyhodou oddeleneho pametoveho prostoru poku me pamet neklame.

Otazka je kolik tech klientu pocitate ze budeme mit pripojenych online, ono schovavat si kazdy deskriptor neni zrovna med, spise bych sel tou cestou rodicovsky proces informuje o to,ze je treba neco udelat (neco jako priznak/vlajka) a procesy obsluhujici klienty se podle toho zaridit, nejspise samy presne vedi kdyz se jim to hodi zpravovat.

Pak tu mame jeste roury a "pojmenovane" roury, k tomu vam nic nereknu, pouzil jsem to asi 2x v zivote, jo funguje to, hojne se to i pouziva viz. nar konstrukce tar | gzip.

Pokud nechcete nic louskat v anglictine nebo je Vam proti srsti zkuste si procist serial na rootu, zejmena od 20kap. nahoru nebo tak nejak, obcas stroji za to i komentare. Me v zacatkach velmi pomohlo kniha Linux Zaciname programovat nez mi ji nejaky paznecht ukradl vcetne batohu, knizko ooo jak mi chybis. Koupil jsem si tedy druhy dil taky neni spatny.

http://www.root.cz/serialy/programovani-pod-linuxem-pro-vsechny/

Drzim palec, developery potrebuje jako sul.

Dotaz: fork() a broadcasting vsem klientum

Odpovědi