FEL ČVUT vyvinula robotickou stavebnici pro mladé programátory. Stavebnice Brian byla navržená speciálně pro potřeby populární Robosoutěže. Jde ale také o samostatný produkt, který si může koupit každý fanoušek robotiky a programování od 10 let, ideální je i pro střední školy jako výuková pomůcka. Jádro stavebnice tvoří programovatelná řídicí jednotka, kterou vyvinul tým z FEL ČVUT ve spolupráci s průmyslovými partnery. Stavebnici
… více »Ubuntu bude pro testování nových verzí vydávat měsíční snapshoty. Dnes vyšel 1. snapshot Ubuntu 25.10 (Questing Quokka).
Společnost Netgate oznámila vydání nové verze 2.8.0 open source firewallové, routovací a VPN platformy pfSense (Wikipedie) postavené na FreeBSD. Přehled novinek v poznámkách k vydání.
Byla vydána nová verze 6.16 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Tor Browser byl povýšen na verzi 14.5.3. Linux na verzi 6.1.140. Další změny v příslušném seznamu.
Člověk odsouzený za obchod s drogami daroval letos ministerstvu spravedlnosti 468 kusů kryptoměny bitcoin, které pak resort v aukcích prodal za skoro miliardu korun. Darováním se zabývá policejní Národní centrála proti organizovanému zločinu (NCOZ). Deníku N to potvrdil přímo ministr spravedlnosti Pavel Blažek (ODS). Podle resortu bylo nicméně vše v souladu s právem.
Svobodný a otevřený multiplatformní editor EPUB souborů Sigil (Wikipedie, GitHub) byl vydán ve verzi 2.5.0. Stejně tak doprovodný vizuální EPUB XHTML editor PageEdit (GitHub).
Na základě národního atribučního procesu vláda České republiky označila Čínskou lidovou republiku za zodpovědnou za škodlivou kybernetickou kampaň proti jedné z neutajovaných komunikačních sítí Ministerstva zahraničních věcí ČR. Tato škodlivá aktivita, která trvala od roku 2022 a zasáhla instituci zařazenou na seznam české kritické infrastruktury, byla provedena kyberšpionážní skupinou APT31, veřejně spojovanou se zpravodajskou službou Ministerstvo státní bezpečnosti (MSS).
Google Chrome 137 byl prohlášen za stabilní. Nejnovější stabilní verze 137.0.7151.55 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 11 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Byl vydán AlmaLinux OS 10 s kódovým názvem Purple Lion. Podrobnosti v poznámkách k vydání. Na rozdíl od Red Hat Enterprise Linuxu 10 nadále podporuje x86-64-v2.
Byl vydán Mozilla Firefox 139.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 139 je již k dispozici také na Flathubu a Snapcraftu.
Nase 2 servery si navzajom rozumeju preco Apache si s nimi nerozumie?Otázka spíš je jaktože si ty dva servery rozumějí. Jak to máš nastavené? To se ti nějak podařilo opravdu nabindovat dva programy na stejný port? Když přijde nové spojení, jak se rozhoduje, který z nich ho dostane? Osobně jsem tohle vždycky řešil tak, že jsem servery nabindoval třeba na :8001, :8002 a :8003 a na portu 80 (443) spustil nějakou proxy (haproxy, nginx, lighttpd…), která podle domény, cesty atd. spojení předala na jeden z těch serverů.
<offtopic>
No, tohle by chtělo malé upřesnění pro úplnost.
Nabindovat dva programy na stejný port samozřejmě lze. Klíčová slova, jak toho docílit:
setsockopt(...)
SOL_SOCKET
SO_REUSEADDR
Tohle^^^ (na obou socketech) zajistí, že se dá pak zavolat bind(...) dvakrát na stejnou adresu.
Háček je „jenom“ v tom, že takové nastavení je irelevantní pro situaci popsanou v dotazu, protože neslouží / nemá sloužit ke sdílení portu několika servery (resp. nevím, jak je v takovém případě definované chování), nýbrž ke sdílení portu několika klienty, kteří pak volají connect(...)
na různé adresy.
Protože TCP spojení je čtveřice (adresa, port, adresa, port), je jasné, že změnou jednoho prvku (kteréhokoliv) se dá vytvořit další spojení. Multiplexování na straně serveru je známější — accept(...)
—, zatímco multiplexování na straně klienta (výše uvedený socket option) je méně známé / méně používané / méně snadno použitelné.
Otázka za 100 bodů by byla, co se stane, když se přes sockety se SO_REUSEADDR
bind(...)
nuté na stejnou adresu připojím dvakrát k témuž serveru (adresa, port). Odpověď neznám; vždy jsem klientský multiplexing používal jen s různými servery. Kdo zná odpověď, třeba ji sem pro zajímavost postne.
</offtopic>
Ne, každý klientský socket je jiné spojení a směřuje jen na ten jeden server, kam vede. Spojení jsou rozlišitelná, protože jedno je [adresa_klienta, port_klienta, adresa_serveru_1, port_serveru_1] a druhé je [adresa_klienta, port_klienta, adresa_serveru_2, port_serveru_2].
Pojmem „multiplexing“ jsem myslel, že se na jednom portu dá udržovat víc oddělených TCP spojení, nikoliv že se něco rozesílá víckrát (což se neděje).
Je to v principu stejné jako psát na straně serveru do socketu, který předtím vrátil accept(...)
. Taky se to pošle jenom tomu jednomu klientovi, který je na daném spojení, přestože adresa:port serveru třeba zrovna obsluhuje naráz spoustu klientů.
Spojení od accept(...)
nepotřebuju nijak poznávat, v tom okamžiku už je vše potřebné zařízeno a identifikováno.
Pokud otevírám víc spojení z jednoho klienta (stejná adresa a stejný port, pomocí SO_REUSEADDR
), musím (jako vždy) při connect(...)
vědět, kam se připojuju, a jednotlivá spojení by se měla lišit — jinými slovy, alespoň adresy serverů nebo alespoň porty serveru/ů by se měly lišit. (Pokud se neliší, k takové situaci směřuje kvízová otázka v mém posledním odstavci výše. Nikdy jsem takovou situaci nezkoušel. Tipuju, že kernel by měl tohle detekovat a vrátit chybu při connect(...)
.)
Mam na jednom porte pustene 2 HTTP serveryNemáte. (Musely by být každý na jiné IP adrese, a to podle dalšího textu nemáte.) Možná řešení jsou dvě: 1. Zjistěte, jak to doopravdy máte, a pro nový server to udělejte stejně. 2. Dát před ty servery reverzní proxy server (nejčastěji se používá nginx, případně HAproxy, šlo by pro to použít i Apache), který bude podle pravidel (doména, URL apod.) směrovat požadavky na příslušné backend servery. Ve skutečnosti jsou nejspíš řešení 1 a 2 ta samá.
Co takhle použít něco jako name-based virtual hosting z Apache jako „frontend + proxy + třetí server“ a ty dva C++ servery jako backendy k tomu? Pak by to mohlo fungovat všechno naráz a ještě k tomu by ty C++ servery mohly být klidně v plaintextu, protože TLS by za ně řešil ten frontend. Name-based virtual hosting na TLS a na stejném portu funguje bez nejmenších potíží, byť zastaralá dokumentace někdy mylně tvrdí opak.
Takhke^^^ jsem měl kdysi na jednom portu asi 20 „serverů“. Tak 10 z nich byly dynamické pseudo-rádoby-domény 3. řádu (hvězdička z pohledu DNS, podadresáře s různými vlastníky z pohledu Apache) a pak tam bylo pár fixních serverů/subdomén, dva byly v Javě, jeden byl v Ruby, pak tam byl taky nějaký Git frontend v nevímčem atd. Dokonce se dalo nastavit, že některé servery se představovaly wildcard certifikátem a jiné měly svůj vlastní certifikát od jiné autority a používaly/vyžadovaly autentifikaci certifikátem. Všechno na jednom portu. (TLS samozřejmě povinné; máme 21. století atd.)
Už dávno ten setup nemám v provozu, ale Apache tohle uměl vzájemně propojit už minimálně 10 let zpátky.
Dokonce mám dojem, že to matchování URL má mnohem jemnější granularitu než „celé“ domény, takže možnostem nastavení se meze nekladou.
Tiskni
Sdílej: