Přemýšlíte, jak začít prázdniny? Už v úterý 1. července se bude konat Virtuální Bastlírna, tedy online setkání bastlířů, techniků, vědců i akademiků, kde se ve volné diskuzi probírají novinky ze světa techniky, ale i jiných zajímavých témat.
Za poslední měsíc jsme byli svědky plamenů několika raket. Zatímco malá raketa od Hondy se úspěšně vznesla a opět přistála, raketa od SpaceX se rozhodla letět všemi směry najednou. Díkybohu méně … více »Linus Torvalds zmínil, že souborový systém Bcachefs zřejmě odstraní z mainline Linuxu v začleňovacím okně pro vydání 6.17. Kent Overstreet mu totiž posílá kód s novou funkcionalitou i pro začlenění do kandidátů na vydání, kdy očekává pouze opravy chyb. Ken Overstreet byl již dříve z vývoje vyloučen kvůli konfliktní komunikaci.
Ministerstvo průmyslu a obchodu propaguje Microsoft. Ten ve spolupráci s Ministerstvem průmyslu a obchodu spouští AI National Skilling Plan v ČR. "Iniciativa Microsoftu přináší konkrétní a praktickou podporu právě tam, kde ji nejvíc potřebujeme – do škol, firem i veřejné správy.", říká ministr průmyslu a obchodu Lukáš Vlček.
Jste český ISP? Vyplněním krátkého dotazníku můžete pomoci nasměrovat vývoj nové generace routerů Turris Omnia [𝕏].
Celkové tržby společnosti Canonical za rok 2024 byly 292 milionů dolarů (pdf). Za rok 2023 to bylo 251 milionů dolarů.
Byla vydána verze 1.88.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Distribuce Tails specializující se ochranu online soukromí uživatele byla vydána ve verzi 6.17. Mimo jiné aktualizuje Tor Browser (14.5.4) a opravuje několik chyb.
Ubuntu nově pro testování nových verzí vydává měsíční snapshoty. Dnes vyšel 2. snapshot Ubuntu 25.10 (Questing Quokka).
Město Lyon posiluje svou digitální suverenitu a postupně nahrazuje software od společnosti Microsoft bezplatnými alternativami, zejména OnlyOffice pro kancelářské aplikace a Linux a PostgreSQL pro systémy a databáze.
Evropská občanská iniciativa Stop Destroying Videogames se snaží o to, aby vydavatelé, kteří spotřebitelům v Evropské unii prodávají videohry nebo na ně udělují licence, měli povinnost tyto hry ponechat ve funkčním (hratelném) stavu i po ukončení podpory ze své strany. Podpořit podpisem tuto iniciativu můžete v Systému pro online sběr podpisů.
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: