V březnu byla oznámena spolupráce GrapheneOS s Motorolou. Nejnovější vlajka Motorola Signature 27 je první Motorola s oficiální podporou GrapheneOS. GrapheneOS (Wikpedie) je varianta Androidu zaměřující se na bezpečnost a soukromí.
Omarchy (Wikipedie) je linuxová distribuce s dlaždicovým správcem oken Hyprland. Založena je na Arch Linuxu. Vydána byla v nové verzi 4.5.0. Nově také pro Apple Silicon, konkrétně pro M1/M2/M3/Neo MacBooky.
Byla vydána nová stabilní verze 8.3 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 156 s bezpečnostními opravami z Chromia 157. Přehled novinek i s náhledy v příspěvku na blogu.
Multimediální přehrávač mpv byl vydán ve verzi 0.42.0. Jde o větší balík změn po bezmála roce. Mimo jiné se lépe integruje s Waylandem nebo rozšiřuje podporu DVD/Blu-ray, např. umožňuje přehrávat rovnou obrazy médií (soubory iso).
Desktopové prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklé sloučením projektů Razor-qt a LXDE bylo vydáno ve verzi 2.5.0. Přehled novinek v poznámkách k vydání.
Byla vydána (𝕏) nová verze 8.0 LTS open source monitorovacího systému Zabbix (Wikipedie). Přehled novinek v oznámení na webu, v poznámkách k vydání a v aktualizované dokumentaci.
Byla vydána verze R14.1.7 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.
Bazzite (Wikipedie), tj. linuxová distribuce vycházející z Fedora Linuxu a optimalizována pro hraní počítačových her, byla vydána ve verzi 45. S Open Gaming Collective (OGC) jádrem a novým Easy Anti-Cheatem pro Linux (EAC Linux v2).
MikroTik zveřejnil vlastní bezpečnostní upozornění potvrzující, že zranitelnost linuxového jádra postihuje také RouterOS 7. Jde o use-after-free při zpracování IPv4 TCP spojení s IP options. Zranitelnost se týká provozu směřujícího na TCP službu samotného routeru, nikoli paketů, které router pouze přeposílá. Opraveno v long-term od 7.24.6, v stable od 7.25.1 a devel od 7.26beta5.
Řešení dotazu:
Osobne bych se nebal zkusit nejakej framework. Ono neco takoveho naprogramovat je otazka nekolika vterin a par radku kodu, akorat bych asi volil neco jineho nez C, to dle toho co tvrdis by mohlo byt pro tebe zbytecne obtizne.
Napriklad v Decku s vibe.d to vypada nejak takto:
import vibe.d;
shared static this() {
listenTCP(55555, toDelegate(&logMe));
}
void logMe(TCPConnection conn) {
appendToFile("/tmp/nejakysoubor", conn.readAllUTF8());
}
-k, --keep-open (Accept multiple connections) .
Normally a listening server accepts only one connection and then quits when the
connection is closed. This option makes it accept multiple simultaneous connections
and wait for more connections after they have all been closed. It must be combined
with --listen. In this mode there is no way for Ncat to know when its network input
is finished, so it will keep running until interrupted. This also means that it will
never close its output stream, so any program reading from Ncat and looking for
end-of-file will also hang.
nc --listen --port=PORT --exec=CMD --continuous
response = data client.send(response)nahradit za:
with open('logfile.log', 'a') as log:
log.write(data)
Může nastat problém se současným zápisem do souboru z více vláken - dá se řešit zámkem, nebo pomocí fronty.
Rychlejší, ale komplikovanější řešení s frontou je http://stackoverflow.com/questions/11983938/python-appending-to-same-file-from-multiple-threads
příklad se zámky by do __init__ přidal
self.lock = threading.Lock()a zápis by pak vypadal:
self.lock.acquire()
with open('logfile.log', 'a') as log:
log.write(data)
self.lock.release()
Ale bez toho omezeni jednim klientem. Da se vlastne spustit vice instanci?Aby mohl paralelně odbavit několik klientů. Předpokládám (jen předpokládám, netvrdím že je to opravdu situace tazatele), že se k serveru má připojit několik klientů a posílat mu nějaká data, která chtějí ukládat do souboru. Pokud by se klient jen připojil, poslal data a odpojil, tak stačí
nc -k.
Pokud však klient data nějak získává postupně a chce je zapisovat průběžně, potřebuje server vlákna aby obsloužil několik klientů najednou.
Ani to není úplně nutné. Pokud klientů (a provozu od nich) není moc a zpracování požadavku netrvá moc dlouho, vystačíte i s jednou smyčkou a poll() (případně epoll() nebo pro tradicionalisty select()).
Jak se konkrétně ty tři varianty (fork, thready, poll/select) implementují, na to jsou na webu hromady příkladů, takže není potřeba to znovu podrobně popisovat.
Pokud však klient data nějak získává postupně a chce je zapisovat průběžně, potřebuje server vlákna aby obsloužil několik klientů najednou.
Dřív, než se problém začne řešit, je potřeba ho nejdřív co nejpřesněji formulovat. Dokud je jeden klient a jedno TCP spojení, je celkem jasné, co znamená zapisovat data z něj do logu. Jakmile mám do jednoho logu zapisovat streamy od několika současně připojených klientů, je potřeba si ujasnit požadavky na to, jak má ten výstup vypadat, protože kvůli bufferování může být výsledek dost divoký.
V praxi nejspíš budeme požadovat, že ve výstupním souboru musí být všechno, co přijde od klientů (což není tak samozřejmé, jak se na první pohled zdá). Kromě toho si typicky definujeme minimální "větu", která musí být ve výsledném souboru zapsaná tak, že nebude přerušená jiným textem. U textového logu to může být třeba řádek, ale dokážu si představit, že někdy může být požadavkem, že záznam skládající se z několika řádků má být pohromadě. Takže je potřeba definovat, jak se pozná "věta", a následně zajistit, aby se zápisy jednotlivých vět serializovaly.
jj, predstav si to jako postu, nekolik lidi ti puse na tvou adresu coz je vlastne ip + port, no a ty jim odpovidas na zpet dle zpetne adresy coz je zase ip + port
Tiskni
Sdílej: