V implementaci Broadcom 802.11 byla zjištěna chyba ve zpracování WPS/EAP, týká se to SDK od roku 2010. Broadcom podle výzkumníka Quentina Kaisera odmítl CVE přidělit. Modemy Huawei a Technicolor jsou používány i v ČR, v LTE routerech, běžných domácích routerech a firemních přístupových bodech, jejich současný počet a zranitelnost konkrétních verzí však zatím neznáme. Více detailů a demo. GitHub / Broadcom 802.11 SDK Detection Toolkit.
Byla vydána nová verze 10.8 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Přibyl balíček DietPi WireGuard.
Oslavte vydání openSUSE Leap 16.1 s námi v Praze! Ve středu 4. listopadu 2026 (den po vydání Leapu 16.1) vás zveme na malou oslavu vydání openSUSE Leap 16.1 do pražské kanceláře SUSE. Připravili jsme pro vás dvě krátké přednášky: … více »
Dle plánu bylo PHP vydáno v nových verzích 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Opraveny jsou kritické zranitelnosti CVE-2026-109618 a CVE-2026-109619 aneb PHP2Shell.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch 24.04-2.1 a 24.04-1.5. S opravou kritických zranitelností.
Společnost Škoda Auto zveřejnila na Printables bezplatné 3D modely příslušenství do svých vozů (držáky na nápoje, pomůcky pro vedení kabelů, mincovníky, háčky na USB kabely a čepice pro kapsy na zadních stranách opěradel sedadel, držáky na telefony a úchyty pro horní upevnění bezpečnostních pásů).
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 170 (pdf).
Dnes v 16:00 (14:00 UTC) budou opraveny 2 kritické zranitelnosti s CVSS 9.2 v PHP.
Nizozemská policie 13. října 2026 zabavila v datacentru Amsterdam Science Park server italského poskytovatele internetových služeb Autistici/Inventati (A/I), a to na základě americké žádosti o mezinárodní právní pomoc.… více »
Ř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: