V terminálovém multiplexoru GNU Screen byly nalezeny a v upstreamu ve verzi 5.0.1 už opraveny bezpečnostních chyby CVE-2025-23395, CVE-2025-46802, CVE-2025-46803, CVE-2025-46804 a CVE-2025-46805. Podrobnosti na blogu SUSE Security Teamu.
Training Solo (Paper, GitHub) je nejnovější bezpečnostní problém procesorů Intel s eIBRS a některých procesorů ARM. Intel vydal opravnou verzi 20250512 mikrokódů pro své procesory.
Byla vydána nová verze 25.05.11 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Nejnovější Shotcut je již vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Svobodný elektronický platební systém GNU Taler (Wikipedie, cgit) byl vydán ve verzi 1.0. GNU Taler chrání soukromí plátců a zároveň zajišťuje, aby byl příjem viditelný pro úřady. S vydáním verze 1.0 byl systém spuštěn ve Švýcarsku.
Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 209. brněnský sraz, který proběhne tento pátek 16. května od 18:00 ve studentském klubu U Kachničky na Fakultě informačních technologií Vysokého učení technického na adrese Božetěchova 2/1. Jelikož se Brno stalo jedním z hlavních míst, kde se vyvíjí open source knihovna OpenSSL, tentokrát se OpenAlt komunita potká s komunitou OpenSSL. V rámci srazu Anton Arapov z OpenSSL
… více »GNOME Foundation má nového výkonného ředitele. Po deseti měsících skončil dočasný výkonný ředitel Richard Littauer. Vedení nadace převzal Steven Deobald.
Byl publikován přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie) za uplynulé dva měsíce. Servo zvládne už i Gmail. Zakázány jsou příspěvky generované pomocí AI.
Raspberry Pi Connect, tj. oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče, byla vydána v nové verzi 2.5. Nejedná se už o beta verzi.
Google zveřejnil seznam 1272 projektů (vývojářů) od 185 organizací přijatých do letošního, již jednadvacátého, Google Summer of Code. Plánovaným vylepšením v grafických a multimediálních aplikacích se věnuje článek na Libre Arts.
Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Dobry den, ucim se sockety v C a tak jsem si vytvoril dva programky, client a server. Server posloucha na urcitem porte, klient se k nemu pripoji a posle mu retezec, ktery mu by predan jako jeden z argumentu.
V serveru je ve strucnosti toto:
while ((size = read(t, buffer, BUF_SIZE)) != 0 ) { printf("Size: %d\n", size); printf("Buffer: %s\n", buffer) }
V klientu:
// send message to server if (write(s, msg, strlen(msg)+1) < 0) { // write error perror("write"); return EXIT_FAILURE; }
Spustim tedy server a vzapeti klient. Server vypise toto a zustane viset v konzoli: (BUF_SIZE je z testovacich duvodu nastavena na hodnotu 2 a klient posila retezec "Ahoj, jak se mas?")
$ ./server -p 1235 Server: Connection from client 127.0.0.1:48502 Size: 2 Buffer: Ah Size: 2 Buffer: oj Size: 2 Buffer: , Size: 2 Buffer: ja Size: 2 Buffer: k Size: 2 Buffer: se Size: 2 Buffer: m Size: 2 Buffer: as Size: 2 Buffer: ?
Program asi zustane visel v tom while cyklu. Myslel jsem, ze kdyz funkce read uz nema co cist, tak vrati nulu a tak cycklus ukonci, ale asi to tak nefunguje.
Myslel jsem, ze kdyz funkce read uz nema co cist, tak vrati nulu a tak cycklus ukonci, ale asi to tak nefunguje.Na čitanie z socketu použi
recv()
a daj mu flag MSG_DONTWAIT
Ok, zmenil jsem to na:
// read message from client while ((size = recv(t, buffer, BUF_SIZE, MSG_DONTWAIT)) != 0 ) { printf("Size: %d\n", size); printf("Buffer: %s\n", buffer) }
A ted to dela toto:
$ ./server -p 1111 Server: Connection from client 127.0.0.1:55527 Size: -1 Buffer: Size: -1 Buffer: Size: -1 Buffer: Size: -1 Buffer: Size: -1 Buffer: Size: -1 Buffer: Size: -1 Buffer: Size: -1 Buffer: Size: -1 Buffer: Size: -1 Buffer: Size: -1 ... a stale cyckli dokola
Tak to udela to co to delalo s tim read(), nacte to po dvou pisemenkach cely ten retezec a pak zustane viset v konzoli.
Vsak ja to vypisuju. Kdyz se podivas na ten muj uplne prvni prispevek. Vypise to vzdy dvojku, dokud ma co cist (= BUF_SIZE) a potom nevypise uz nic. viz:
$ ./server -p 1235 Server: Connection from client 127.0.0.1:48502 Size: 2 Buffer: Ah Size: 2 Buffer: oj Size: 2 Buffer: , Size: 2 Buffer: ja Size: 2 Buffer: k Size: 2 Buffer: se Size: 2 Buffer: m Size: 2 Buffer: as Size: 2 Buffer: ?
Pratele, co takhle obcas nahlednout do dokumentace? Clovek se tam docte neuveritelne veci.
$ man 3 read ... * If O_NONBLOCK is set, read() shall return -1 and set errno to [EAGAIN]. ... $ man recv ... If no messages are available at the socket, the receive calls wait for a message to arrive, unless the socket is non-blocking (see fcntl(2)), in which case the value -1 is returned and the external variable errno set to EAGAIN. The receive calls normally return any data available, up to the requested amount, rather than waiting for receipt of the full amount requested. ... MSG_DONTWAIT (since Linux 2.2) Enables non-blocking operation; if the operation would block, the call fails with the error EAGAIN (this can also be enabled using the O_NONBLOCK with the F_SETFL fcntl(2)). ...
Ehm, stydim se, ale stale v tom nevidim reseni toho problemu.
Kdyz u recv() nastavim MSG_DONTWAIT, tak mi to v tom whilu vraci same -1 a nic se nenacte.
Tak jinak, kdyz u recv() nastavim MSG_DONTWAIT chova se to podivne. Server bezi a ja opakovane spoustim klienta a deje se toto:
$ ./server -p 1111 Server: Connection from client 127.0.0.1:48953 Size: 2 Buffer: Ah Size: 2 Buffer: oj Size: 2 Buffer: , Size: 2 Buffer: ja Size: 2 Buffer: k Size: 2 Buffer: se Size: 2 Buffer: m Size: 2 Buffer: as Size: 2 Buffer: ? Server: Connection from client 127.0.0.1:48957 Server: Connection from client 127.0.0.1:48966 Size: 2 Buffer: Ah Size: 2 Buffer: oj Size: 2 Buffer: , Size: 2 Buffer: ja Size: 2 Buffer: k Size: 2 Buffer: se Size: 2 Buffer: m Size: 2 Buffer: as Size: 2 Buffer: ? Server: Connection from client 127.0.0.1:48967 Server: Connection from client 127.0.0.1:48968 Server: Connection from client 127.0.0.1:48969 Server: Connection from client 127.0.0.1:48970
To znamena ze prenos toho retezce se povede "jak kdy"... :-/
No ano. Kdyz nejsou zadna data na cteni, tak vrati -1 a nastavi errno
(man errno
) na EAGAIN.
Ja nevim, jaky je presne vas problem. Nejspis klient po odeslani dat nezavre socket, takze server porad ceka na dalsi, nebo mozna tam mate jiny nekonecny cyklus. Dejte sem osekane ale kompletni zdrojaky, ze kterych jde zkompilovat funkcni program. Pak bude videt, kde je chyba.
klient: http://pastebin.com/d58eeb1f7
server: http://pastebin.com/f32789de0
Tohle by melo fungovat.
--- server.old.cc +++ server.cc @@ -1,4 +1,5 @@ #include <cstring> +#include <cerrno> #include <string> #include <unistd.h> #include <cstdlib> @@ -21,7 +22,7 @@ { int s, t, sinlen, opt, size, port = 0; struct sockaddr_in sin; - char buffer[BUF_SIZE]; + char buffer[BUF_SIZE+1]; // +1 == space for ending \0 string message; // we accept two arguments @@ -89,13 +90,43 @@ if (DEBUG) cout << "Server: Connection from client " << inet_ntoa(sin.sin_addr) << ":" << ntohs(sin.sin_port) << endl; + message = ""; // read message from client - while ((size = recv(t, buffer, BUF_SIZE, MSG_DONTWAIT)) != -1 ) - { - cout << "Size: "<< size << endl; - cout << "Buffer: "<< buffer << endl; - message += buffer[BUF_SIZE]; - } + for (;;) + { + size = recv(t, buffer, BUF_SIZE, MSG_DONTWAIT); + + if (size == -1) + { + if (errno == EAGAIN) + { + // no data, try read again + continue; + } + else + { + // some error + perror("recv"); + exit(EXIT_FAILURE); + } + } + + if (size == 0) + // client closed connection + break; + + buffer[size] = 0; // zero-end received string + + cout << "Size: "<< size << endl; + cout << "Buffer: "<< buffer << endl; + + message += buffer; + + if (buffer[size-1] == 0) + // terminating zero received from client + // => end of data transfer + break; + } if (DEBUG) cout << "Server: String received from client: |" << message << "|" << endl;
Dekuji moc, ze jste si s tim dal tu praci. Zaroven ale nechapu, proc jste to tedy upravil a pod to napsal ze takhle se to vlastne delat nema ale dela se o jinak. Proc jste to tedy nenupravil rovnou na tu podobu jak to ma byt spravne? Neberte to jako ze si stezuji, cenim si toho, jen toto opravdu nechapu. Zaroven bych vas chtel poprosit jestli byste jeste mohl napsat tedy tu upravu, jak by to tedy melo spravne byt bez busy waiting. Mockrat dekuji.
Protoze vam nevidim do hlavy a nevim, k cemu to dal pouzijete. Ve zdrojacich jste pouzil neblokujici cteni a ja upravil nezbytne minimum, aby to zaclo chodit.
Zmena je prosta: nahradte volani recv
funkci read
. A pak muzete vyhodit zbytecne if (errno == EAGAIN)
(cast else
tam nechte).
Coz pouzit poll/epoll?
close()
nebo shutdown()
?
Diskusi o recv()
si nevšímejte, read
a write
funguje v tomto případě stejně dobře, jen u recv
máte nějaké extra možnosti, které jsou specifické pro sockety. Ty Vás ale teď moc nemusí zajímat.
write
a read
v klientovi použít funkci shutdown
a jednostranně spojení ukončit, pak to bude fungovat. Druhá možnost je, že si přečtená data v serveru budete postupně ukládat do nějakého bufferu, a v případě, že se obsah nebo délka bufferu bude něčemu rovnat, tak čtecí cyklus ukončíte. Postupné slepování v bufferu musíte použít proto, že Vám původní celá zpráva může přijít postupně po kouskách. Ten druhý postup je univerzální i pro případ, že byste chtěl čtení a zápis alternovat v nějakém delším dialogu, tak jako to dělají normální servery.
Vyzkousim tu moznost se shutdown (protoze ta druha se mi zda nejak slozita nejsem si jisty, zda ji zcela chapu) a dam vedet jestli to pomohlo.
Tiskni
Sdílej: