Dotaz: Sucasene citanie a zapis zo soketu - chat klient

[Miso Miso]

Ahojte,

pokusam sa napisat chat program(server a klient). Server cast riesim pomocou klasickeho selectu. Problem mam pri programovani klienta. Totiz potrebujem zaroven citat a zapisovat do soketu, ktorym je klient pripojeny na server.

Citat potrebujem neustale(server moze poslat spravu od ostatnych klientov v ktoromkolvek okamihu - tuto spravu musim vypisat). Zapisovat potrebujem po tom, co pouzivatel zada spravu na odoslanie.

Zatial som to spravil tak, ze jeden thread cita zo soketu a druhy thread cita z prikazoveho riadku a po stlaceni enter zapise do soketu text. Cize z dvoch threadov zaroven zapisujem a citam z jedneho soketu. Klient sa tvari tak, ze to funguje ale pochybuje o bezpecnosti tohto riesenia.

Dalsia moznost je zaregistrovat soket do mnozin na zapis a citanie (FD_SET). A pomocou select citat zo soketu a zapisovat do soketu (ak je pripraveny text na zapis). Taketo riesenie vsak spotrebuje 100% procesoroveho casu pretoze soket je vzdy pripraveny na zapis a teda select ihned skonci.

Este som rozmyslal nad tym, ze potom ako uzivatel napise spravu modifikujem mnozinu soketov cakajucich na zapis. toto vsak tiez nie je asi najbezpecnejsie riesenie :).

Ako by ste riesili klienta?

Za cennu radu dakujem Michal

Odpovědi

[Luboš Doležel (Doli)]

Tak si mezi selecty dejte usleep().

[Miso Miso]

toto riesenie sa mi vidi take hackerske obidenie problemu :), co sa mi velmi nepaci.

[Michal Kubeček]

Zatial som to spravil tak, ze jeden thread cita zo soketu a druhy thread cita z prikazoveho riadku a po stlaceni enter zapise do soketu text. Cize z dvoch threadov zaroven zapisujem a citam z jedneho soketu. Klient sa tvari tak, ze to funguje ale pochybuje o bezpecnosti tohto riesenia.

Pokud to ošetříte mutexem, neviděl bych v tom problém. Nebo když použijete streamové funkce, které to zamykají automaticky.

Este som rozmyslal nad tym, ze potom ako uzivatel napise spravu modifikujem mnozinu soketov cakajucich na zapis. toto vsak tiez nie je asi najbezpecnejsie riesenie

Proč? Ale asi bych použil spíš poll(), tam si nemusíte hrát s těmi nepřehlednými množinami a jen přehazujete jeden příznak. Nebo jste to myslel tak, že byste změnil množinu, zatímco v druhém threadu běží ten select()? To by asi opravdu nešlo.

[Miso Miso]

Pokud to ošetříte mutexem, neviděl bych v tom problém. Nebo když použijete streamové funkce, které to zamykají automaticky.

neviem ci sme sa pochopili. Ja v tom vidim problem asi taky, ze ked spravim v jednom threade synchornizovany recv pomocou mutexu a do soketu sa nikdy nic nepride, potom sa v druhom threade nidky nedostanem k zapisu do soketu. Inak by som musel pouzit neblokovaci rezim, taketo riesenie by vsak bolo velmi neefektivne pretoze recv by stale okamzite skoncil a hned na to by sa spustal znova.

Okrem toho mate pravdu, druhe riesenie asi naozaj nepojde.

[Michal Kubeček]

Myslel jsem to spíš tak, že v jednom threadu by čekal poll(), až bude možné číst, a mutex by se zamykal až na samotný read(). Ve druhém threadu by se zamkl mutex na zápis, když by bylo potřeba. To by mělo projít, ale nezkoušel jsem to.

[maleprase]

pres select kontroluj akorat cteni. zapis provadis stejne az ve chvili kdy mas neco ve vstupni fronte kterou muzes kontrolovat vzdy po selectu nebo po jeho timeoutu.

[#Tom]

Mně se také zalíbíl poll - pole se nachystalo jenom jednou a čistěji. Také jsem psal kecací prográmek (jako úlohu do prográmka v C). Žádná vlákna ani podprocesy jsem nepotřeboval ani u klienta, ani u serveru. Jinak se mi osvědčilo u klienta hlídat funkcí poll i standardní vstup, takže šlo snadno obsloužit jak psaní na klávesnici, tak přijímání zpráv.

[Michal Kubeček]

V tomto případě opravdu stačí select() nebo poll(). Řešení pomocí threadů nebo samostatných procesů je vhodnější tam, kde je větší množství klientů a vyřízení požadavku trvá netriviální dobu (protože během vyřizování jednoho požadavku se nemůžete bavit s dalšími klienty).

[Miso Miso]

Naozaj super napad. pollovat standardny vstup. dakujem. Momentalne vsak este neviem ci riesenie nebude zalozene na ncurses. V tom pripade by som do jedneho okna zapisoval a z druheho cital. teda by som potreboval zavesit poll na ncurses okno.

Nakoniec to asi spravim tak ako mi niekto poradil v predchadzajucom prispevku. nastavim do selectu nejaky "rozumny" timeout a stale ked select skonci tak sa pozriem do fronty sprav ci mozem nieco zapisat a ak ano tak to zapisem. Je to sice dost nepruzne ale aspon bezpecne riesenie a nezabera tolko proceseroveho casu. (ako napr. zaregistrovanie soketu aj na zapis - vtedy sa select skonci hned)

Ak niekoho napadne lepsie riesenie este sa ozvite. Chcelo by to nejaky asynchronny soket :), ktoremu by som nastavil callbacky na send a receive :).

Zatial dakujem, michal

[#Tom]

Můžete se kouknot na moje řešení (cv9), ale moc uhlazený kód tam není, tento program byl napsán v ještě větším spěchu než ostatní (za 3-4 dny) a kvalitou nepřekypuje.

[Miso Miso]

Dakujem za riesenie. trochu som zazmatkoval, ked som povedal ze treba poll zavesit na okno :). jasne ze na poll staci zavesit standardny vstup, kedze ncurses tiez iba citaju standardny vstup, ked pouzijem wgetch(). Sory ze som sa takto pomylil a tym Vas este otravoval.