abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 12:33 | Humor

Byl vydán remake filmu Ghost in the Shell. Tentokrát v Bashi. Zhlédnout lze online na "ssh ghost@theshell.xyz" [Hacker News].

Ladislav Hagara | Komentářů: 11
včera 20:40 | Zajímavý článek

Lukáš Růžička v článku S Hydrogenem za lepší rytmus aneb bubeníkem snadno a rychle na MojeFedora.cz představuje automatického bubeníka s názvem Hydrogen (Wikipedie): Hydrogen je velmi vydařený program, který rozhodně nesmí chybět ve výbavě žádného linuxového muzikanta. Umožňuje nejen vytváření jednoduchých bicích doprovodů, ale také sofistikované programování bicích a perkusí, jehož výsledek se naprosto vyrovná drahým

… více »
Ladislav Hagara | Komentářů: 12
včera 13:55 | Zajímavý projekt

UPSat (Twitter) je první open source nanodružice (CubeSat). Jedná se o společný projekt nadace Libre Space Foundation a University of Patras. Repozitáře projektu jsou k dispozici na GitHubu. Pod Libre Space Foundation patří také projekt SatNOGS (zprávička), projekt globální sítě open source pozemních satelitních stanic, vítězný projekt soutěže The Hackaday Prize 2014. UPSat je součástí mise QB50 (Twitter). ID UPSatu je GR02. GPS přijímač na UPSatu je od české společnosti SkyFox Labs. Součástí mise QB50 je i česká nanodružice VZLUSAT-1 s ID CZ02.

Ladislav Hagara | Komentářů: 4
21.4. 15:00 | Komunita

V diskusním listu Thunderbird planning vývojáři poštovního klienta Thunderbird řeší, zda by nebylo možné budoucí Thunderbird postavit nad webovými technologiemi, tj. nad Electronem, stejně jako například Nylas Mail. Gecko, nad kterým je Thunderbird postaven, se má hodně změnit. V plánu je odstranění vlastností, které Firefox už nepotřebuje, ale Thunderbird je na nich závislý [Hacker News, reddit].

Ladislav Hagara | Komentářů: 96
21.4. 10:22 | Bezpečnostní upozornění

Společnost Oracle vydala čtvrtletní bezpečnostní aktualizaci svých softwarových produktů (CPU, Critical Patch Update). Opraveno bylo celkově 299 bezpečnostních chyb. V Oracle Java SE je například opraveno 8 bezpečnostních chyb. Vzdáleně zneužitelných bez autentizace je 7 z nich. V Oracle MySQL je opraveno 39 bezpečnostních chyb. Vzdáleně zneužitelných bez autentizace je 11 z nich.

Ladislav Hagara | Komentářů: 8
21.4. 10:00 | Pozvánky

V úterý 25. dubna proběhne další Prague Containers Meetup. Přijďte se nechat inspirovat jak zlepšit build/delivery pipeline vašich kontejnerových aplikací.

little-drunk-jesus | Komentářů: 2
20.4. 21:33 | Komunita

Na Launchpadu se objevilo kódové jméno následující verze Ubuntu. Ubuntu 17.10 bude Artful Aardvark (mazaný hrabáč) [OMG! Ubuntu!].

Ladislav Hagara | Komentářů: 11
20.4. 20:11 | Zajímavý software

MojeFedora.cz informuje, že společnost Nylas oznámila vydání verze 2.0 poštovního klienta Nylas Mail (původně Nylas N1), která již plně podporuje Linux. Obchodní model společnosti je tzv. open core. Samotný klient je open source, ale uživatel si musí připlatit za některé pokročilé funkce. V základu se lze připojit k GMailu nebo libovolnému účtu přes IMAP. Podpora Exchange je pouze v placené verzi. Klient je napsaný nad Electronem.

Ladislav Hagara | Komentářů: 12
20.4. 15:55 | Zajímavý článek

České centrum pro investigativní žurnalistiku (ČCIŽ) publikovalo na svých stránkách článek s názvem Je česká státní správa „rukojmím Microsoftu“?. Drtivá většina české veřejné správy je závislá na výrobcích softwarového gigantu Microsoft – a nijak zvlášť jí to nevadí.

Ladislav Hagara | Komentářů: 21
20.4. 02:48 | Nová verze

Google Chrome 58 byl prohlášen za stabilní. Nejnovější stabilní verze 58.0.3029.81 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo 29 bezpečnostních chyb. Mezi nimi i chyba umožňující phishing s unicode doménami.

Ladislav Hagara | Komentářů: 0
Chystáte se pořídit CPU AMD Ryzen?
 (4%)
 (35%)
 (0%)
 (7%)
 (45%)
 (9%)
Celkem 285 hlasů
 Komentářů: 32, poslední dnes 12:24
    Rozcestník
    Štítky: není přiřazen žádný štítek

    Dotaz: Sokety - přijímání zpráv s variabilní délkou

    27.4.2010 00:20 Tomáš Skočdopole | skóre: 13
    Sokety - přijímání zpráv s variabilní délkou
    Přečteno: 358×
    Zdravím,

    Řeším komunikaci klient-server a chtěl bych zde poprosit o vysvetleni par nejasnosti.

    1) Jakym zpusobem se dělá přijímací část, která by měla být schopna přijmout zprávy, které budou mít promennou délku. Každá zpráva by koncila nejspis znakem nového řádku nebo \0. Pro příjem bych použil funkci recv() ale neni mi jasne toto: Pokud zadam velikost bufferu napriklad 10 byte. A ted poslu zpravu, ktera ma treba 8 byte. Vrati se tato funkce s osmi byte v bufferu, nebo zustane cekat na zbyle 2? Pripadne bude cekat na zbyle 2 dokud nevyprsi nejaky timeout?

    2) Dal jsem se chtel zeptat na hlidani toho ukoncovaciho znaku zpravy - nacitat po jednom byte se mi zda jako hloupost. Takze bych to videl na okontrolovani celeho bufferu, co prijmula funkce recv, zda neobsahuje ukoncovaci znak.

    3) Kdyz poslu pres sendv jednu zpravu delce o 3 byte a nasledne druhou zpravu o delce 3 byte a na druhe strane bude funkce recv () cekat s bufferem o velikosti 10 - vrati se mi prvne prvni zprava a potom druha, nebo tyto dve zpravy mi recv vrati za sebou v jednom volani?

    4) Vubec netusim, jakou zvolit velikost bufferu? Budou odesilány zprávy o průměrné velikosti 10 byte, max 40 byte.

    5) Je potreba do kazde zpravy nejak vkladat jeji velikost? Nebo to lze udelat i bez ni?

    Predem vsem mnohokrat dekuji za cenne rady a informace! Zdravim Tomas

    Odpovědi

    27.4.2010 08:07 rastos | skóre: 60 | blog: rastos
    Rozbalit Rozbalit vše Re: Sokety - přijímání zpráv s variabilní délkou
    1) Jakym zpusobem se dělá přijímací část, která by měla být schopna přijmout zprávy, které budou mít promennou délku.

    Ja to riešim tak, že každá správa má na začiatku 32-bitový int, ktorý hovorí o dĺžke zvyšku správy. Tebe vlastne stačí 1 bajt lebo máš krátke správy.
    Pokud zadam velikost bufferu napriklad 10 byte. A ted poslu zpravu, ktera ma treba 8 byte. Vrati se tato funkce s osmi byte v bufferu, nebo zustane cekat na zbyle 2?
    man recv(): The receive calls normally return any data available, up to the requested amount, rather than waiting for receipt of the full amount requested.

    Z toho vyplýva, že ak je dostupných 8 bajtov, tak sa sa prečíta 8 bajtov a recv() vráti 8 bajtov. Na zvyšné 2 sa nečaká.
    2) Dal jsem se chtel zeptat na hlidani toho ukoncovaciho znaku zpravy - nacitat po jednom byte se mi zda jako hloupost.
    Dúfam, že dnešné OS sú už natoľko chytré, že si jadro udržuje v pamäti nejaký buffer prijatých bajtov a recv() len vráti to čo v tom buffer-i nájde, takže ani čítanie po jednom znaku by nemuselo byť pomalé. Môžeš to ale riešiť aj tak, že si budeš sčítavať koľko bajtov recv() prečítalo a volať recv() opakovane až kým celkový počet prečítaných znakov nedosiahne počet, ktorý si chcel pôvodne prečítať.
    3) Kdyz poslu pres sendv jednu zpravu delce o 3 byte a nasledne druhou zpravu o delce 3 byte a na druhe strane bude funkce recv () cekat s bufferem o velikosti 10 - vrati se mi prvne prvni zprava a potom druha, nebo tyto dve zpravy mi recv vrati za sebou v jednom volani?
    Vráti sa to v jednom volaní. Pre také množstvá dát ako prenášaš je vhodné použiť socket option TCP_NODELAY - inak vysielač dáta skutočne pošle až po naplnení nejakej veľkosti odosielacieho bufferu alebo vypršaní nejakého timeout-u.
    4) Vubec netusim, jakou zvolit velikost bufferu? Budou odesilány zprávy o průměrné velikosti 10 byte, max 40 byte.
    Zvoľ 40 bajtov a zariaď sa podľa toho čo recv() vráti.
    5) Je potreba do kazde zpravy nejak vkladat jeji velikost? Nebo to lze udelat i bez ni?
    Myslím, že bude jednoduchšie ak tam tá veľkosť (a prípadne nejaký identifikátor typu správy) bude. Ale neexistuje jediná správna cesta.
    27.4.2010 08:21 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Sokety - přijímání zpráv s variabilní délkou
    Dúfam, že dnešné OS sú už natoľko chytré, že si jadro udržuje v pamäti nejaký buffer prijatých bajtov a recv() len vráti to čo v tom buffer-i nájde, takže ani čítanie po jednom znaku by nemuselo byť pomalé
    I v takovém případě se ale bude muset přepínat mezi kontextem jádra a aplikace pro každý bajt místo pro celý buffer, takže to pomalejší bude. Ono je to v tomto případě asi jedno, ale načítat ta data po jednom bajtu je prostě ošklivé :-)
    27.4.2010 18:27 Tomáš Skočdopole | skóre: 13
    Rozbalit Rozbalit vše Re: Sokety - přijímání zpráv s variabilní délkou
    Zdravim,

    tak ted jsem zjistil, ze TCP_NODELAY nemam definovane. Pouzivam jadro 2.6.32.

    V knize Unix Network Programming od Stevens, Fenner, Rudoff tuto volbu ale popisuji.

    Tomas
    27.4.2010 08:18 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Sokety - přijímání zpráv s variabilní délkou
    Ad 1) Vrátí 8 bajtů (nebo klidně méně) v bufferu.

    Ad 2) Od toho je tam ten buffer, načtete větší množství dat a pak budete hledat v bufferu.

    Ad 3) Může se to vrátit jako libovolný počet zpráv – celé jako jedna „zpráva“, rozdělené do dvou zpráva jako 3+3 bajty ale klidně taky jako 2+4, 6 volání po jednom bajtu…

    Ad 4) Pokud je to takhle malý objem dat, zvolil bych buffer o maximální možné délce zprávy.

    Ad 5) Předpokládám, že se celou dobu bavíme o TCP/IP komunikaci. Ta není založena na zprávách, ale na proudu bajtů – sendv() i recv() pak vždy představují jen jakési okno do tohoto proudu, nejsou to jednotlivé zprávy. Tzn. rozdělení na zprávy si musíte udělat sám, třeba tak, že si délku zprávy napíšete na její začátek. V případě UDP komunikace (založené na zprávách) byste měl použít recvfrom(), pak budete dostávat celé zprávy po jedné.
    27.4.2010 10:37 chrono
    Rozbalit Rozbalit vše Re: Sokety - přijímání zpráv s variabilní délkou
    A len doplním, že ak pôjde o UDP správy, tak tie môžu prísť v akomkoľvek poradí alebo niektoré nemusia prísť vôbec (ale je to rýchlejšie ako pri TCP, takže vhodný protokol záleží od konkrétneho použitia).
    27.4.2010 10:51 Ivan
    Rozbalit Rozbalit vše Re: Sokety - přijímání zpráv s variabilní délkou
    O rozdeleni na zpravy se postara PUSH Flag v hlavicce TCP packetu. Socket API bohuzel nema moznost PUSH flag vynutit. Pokud ale otevrete socket s option TCP_NODELAY, tak rozumny kernel bude davat (P) flag za kazdou zpravu. Pokud prijimajici kernel uvidi (P) flag v hlavicci tak nesmi data ponechat v prijimajicim bufferu a musi je predat aplikaci.

    Dalsi moznost - ale to uz je hodne velka reznicina - je podivat se na OOB - out of bound data.

    Ivan PS: koukni se na tcpdump jestli uvidis v hlavickach (P). Treba HDR replikace Informixu na AIXu dava PUSH flag za kazdych 4096 bajtu TCP streamu(1 stranka).

    27.4.2010 10:52 Ivan
    Rozbalit Rozbalit vše Re: Sokety - přijímání zpráv s variabilní délkou
    Viz: http://www.unixguide.net/network/socketfaq/2.11.shtml
    27.4.2010 10:55 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Sokety - přijímání zpráv s variabilní délkou
    Ani to ale nezajistí rozdělení na zprávy – pokud třeba pakety dorazí v opačném pořadí nebo se někde cestou spojí, může přijít víc zpráv současně. Tzn. zajistíte tím, že data nebudou v bufferu čekat zbytečně, ale ona tam někdy také mohou čekat nezbytně.
    27.4.2010 11:20 pht | skóre: 48 | blog: pht
    Rozbalit Rozbalit vše Re: Sokety - přijímání zpráv s variabilní délkou
    Ad 1) Vrátí 8 bajtů (nebo klidně méně) v bufferu.

    To "méně" záleží na nastavení SO_RCVLOWAT (minimální počet bajtů které se vrací - default je 1) a na použití blokujících / neblokujících socketů. Pokud je neblokující a nemáte data, může vrátit -1 a EAGAIN.
    Ad 2) Od toho je tam ten buffer, načtete větší množství dat a pak budete hledat v bufferu.

    Tak. Čtení znak po znaku je obvykle známkou chatrného designu aplikace.
    Ad 3) Může se to vrátit jako libovolný počet zpráv – celé jako jedna „zpráva“, rozdělené do dvou zpráva jako 3+3 bajty ale klidně taky jako 2+4, 6 volání po jednom bajtu…

    Tohle opravdu záleží na tom, jestli používáte datagramový socket (SOCK_DGRAM) nebo proudový (SOCK_STREAM). Datagramy se vrací v jednom kuse. Pokud máte moc malý buffer na celý datagram, je zbytek datagramu zahozen. Proudový socket se tváří jako jeden proud (překvapivě) dat, takže bude příchozí pakety slepovat, nebo naopak si můžete vyžádat jen 10 bajtů a pak dalších 10 a nic se nezahodí. Jestli dostanete 3+3 nebo 6 obvykle záleží na tom jak rychle stihnete ty první 3 vybrat.
    Ad 4) Pokud je to takhle malý objem dat, zvolil bych buffer o maximální možné délce zprávy.

    Normálně se buffer zarovnává na násobky 4096 bajtů, i když to může vypadat jako plýtvání.
    Ad 5) Předpokládám, že se celou dobu bavíme o TCP/IP komunikaci. Ta není založena na zprávách, ale na proudu bajtů – sendv() i recv() pak vždy představují jen jakési okno do tohoto proudu, nejsou to jednotlivé zprávy. Tzn. rozdělení na zprávy si musíte udělat sám, třeba tak, že si délku zprávy napíšete na její začátek. V případě UDP komunikace (založené na zprávách) byste měl použít recvfrom(), pak budete dostávat celé zprávy po jedné.
    Souhlas, až na to, že to chování záleží na typu soketu a ne na protokolu. (Viz také můj popis výše.)

    Pokud používáte proudový socket, záleží na Vás, jak si vyřešíte rozdělení zpráv. Můžete na začátek zprávy dát délku nebo naopak můžete zprávu ukončit nějakou sekvencí jednoho a více bajtů. Oboje má svoje plus a mínus.

    In Ada the typical infinite loop would normally be terminated by detonation.
    27.4.2010 12:21 Radovan Garabík
    Rozbalit Rozbalit vše Re: Sokety - přijímání zpráv s variabilní délkou
    Ak o protokole nie je rozhodnuté "zhora", pozri si netstrings, môže to byť celkom dobrá inšpirácia.

    27.4.2010 13:22 Tomáš Skočdopole | skóre: 13
    Rozbalit Rozbalit vše Re: Sokety - přijímání zpráv s variabilní délkou
    Zdravim!

    Predne dekuji vsem za reakce!

    Abych doupresnil - jedna se o TCP komunikaci.

    Takze recv () vrati ihned vsechny dostupne data co jsou, pripadne kdyz jich je vic, nez nastaveny buffer, tak dalsi dostupna data vrati v dalsim volani - zadna data se nezahodi. Pokud budu pouzivat recv () v blokujicim rezimu, tak bude cekat dokud neprijdou nejaka data. Pokud by prisel jeden bajt, tak ho vrati okamzite? Nebo se bude cekat na nejake vetsi mnozstvi, pripadne timeout? To se pripadne nastavuje jak?

    Takze pokud to dobre chapu, na vysilaci strane musim nastavit TCP_NODELAY abych zajistil, ze data, ktera do sendv zadam se odeslou okamzite. A na prijimaci strane volat recv tolikrat, dokud nenarazim na ukoncovaci znak zpravy. Buffer tedy zarovnam na 4096 bajtů. Kazdy vraceny buffer projdu a zjistim, zda obsahuje ukoncovaci znak. A proste budu muset pocitat s tim, ze by prisel i zacatek nasledujici zpravy.

    Dekuji! Tomas
    27.4.2010 14:56 Ivan
    Rozbalit Rozbalit vše Re: Sokety - přijímání zpráv s variabilní délkou
    Jeste muzes stringy prefixovat delkou a volat recv s MSG_PEEK. Tim ziskas delku zpravy a pak muzes nasledne cist celou zpravu.
    27.4.2010 18:26 psonek | skóre: 20 | blog: psonek
    Rozbalit Rozbalit vše Re: Sokety - přijímání zpráv s variabilní délkou
    Na to, ze ti recv vrati vsechno bych se nikdy nespolehal. To samo treba u cteni ze souboru pres read - viz manual. Pokud to chces mit bez problemu, tak musis vedet kolik bajtu chces jeste cist - cili bud zpravy pevne delky nebo jeste lepe jak tu uz psali - na zacatku zpravy aby byla delka.

    Pokud se budes spolehat, ze ti recv vrati vsechno, tak se jednou zmeni podminky (rychlost site, jiny OS apod) a prestane to fungovat. Klidne to cteni taky muze byt kdykoliv preruseno signalem.
    27.4.2010 19:44 pht | skóre: 48 | blog: pht
    Rozbalit Rozbalit vše Re: Sokety - přijímání zpráv s variabilní délkou
    Abych doupresnil - jedna se o TCP komunikaci.

    V tom případě nevidím důvod se zahazovat s recv a send, použijte normální read a write.
    Pokud by prisel jeden bajt, tak ho vrati okamzite?
    Ano.
    Nebo se bude cekat na nejake vetsi mnozstvi, pripadne timeout? To se pripadne nastavuje jak?
    Viz setsockopt SO_RCVLOWAT (tohle podle manuálu ale nefunguje na linuxu), případně u recv lze také použít flag MSG_WAITALL.

    Timeout přes setsockopt SO_RCVTIMEO.

    Pro komplikovanější operace lze použít select().
    sendv
    Pokud vím tak sendv neexistuje, maximálně tak writev.
    A na prijimaci strane volat recv tolikrat, dokud nenarazim na ukoncovaci znak zpravy. Buffer tedy zarovnam na 4096 bajtů. Kazdy vraceny buffer projdu a zjistim, zda obsahuje ukoncovaci znak. A proste budu muset pocitat s tim, ze by prisel i zacatek nasledujici zpravy.

    V jazyce C je nejlépe na to udělat cyklický fifo buffer. Např. http://www.vias.org/cppcourse/chap20_05.html nebo http://www.answers.com/topic/circular-buffer-1.

    Jinak doporučuju míň teoretizovat a spíše program otestovat na různé kombinace možností.
    In Ada the typical infinite loop would normally be terminated by detonation.
    27.4.2010 21:33 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Sokety - přijímání zpráv s variabilní délkou
    Kazdy vraceny buffer projdu a zjistim, zda obsahuje ukoncovaci znak.
    Jenom pro jistotu: vždy dostanete hodnotu, která určuje, kolik bajtů bylo do bufferu skutečně zapsáno. Buffer tedy nemůžete procházet celý, ale jenom tolik bajtů z něj, kolik tam bylo zapsáno.
    Josef Kufner avatar 3.5.2010 02:56 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Sokety - přijímání zpráv s variabilní délkou
    5) Je potreba do kazde zpravy nejak vkladat jeji velikost? Nebo to lze udelat i bez ni?
    Pokud použiješ textový protokol a každou zprávu na samostatný řádek, tak se bez délky obejdeš. Nebo docela dobrá je taky lispová syntaxe – vemeš závorku a čteš dokud nenajdeš druhou do páru (přitom plníš seznam).

    Rozhodně doporučuju udělat hezký i za cenu, že se bude přenášet o pár bajtů víc. Hezky udělaný jsou POP3 a XMPP, protože POP3 je jednoduchý řádkový a XMPP má univerzální a rozšiřitelný formát (ale pro jednoduché věci radši ten lisp než XML).

    Hlavně ale počítej s tím, že TCP negarantuje doručení zpráv! Takže si musíš ověřovat, která zpráva byla doručena jako poslední pro případ nekorektně uzavřeného spojení. TCP garantuje pouze pořadí dat, ale doručení jen při správně uzavřeném spojení. Kvůli tomuhle se na Jabberu ztrácejí zprávy, když ti vypadne kabel a server si toho nevšimne...
    Hello world ! Segmentation fault (core dumped)

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.