Evropská komise zahájila tři vyšetřování týkající se cloudových platforem Amazon Web Services (AWS) a Microsoft Azure. Evropská exekutiva, která plní také funkci unijního antimonopolního orgánu, chce mimo jiné určit, zda jsou americké společnosti Microsoft a Amazon v cloudových službách takzvanými gatekeepery, tedy hráči, kteří významně ovlivňují provoz internetu a musí dle nařízení o digitálních trzích (DMA) na společném trhu
… více »Společnost Meta Platforms vyhrála ostře sledovaný spor o akvizici sítě pro sdílení fotografií Instagram a komunikační aplikace WhatsApp. Podle amerického soudu firma jejich převzetím neporušila antimonopolní zákon, protože si tak nemonopolizovala trh sociálních sítí. Žalobu na Metu podala před pěti lety americká Federální obchodní komise (FTC). FTC argumentovala, že Meta, tehdy známá jako Facebook, koupila tyto dvě společnosti v letech 2012 a 2014 proto, aby s nimi nemusela soutěžit.
Home Assistant včera představil svůj nejnovější oficiální hardware: Home Assistant Connect ZBT-2 pro připojení zařízení na sítích Zigbee nebo Thread.
Byla vydána verze 9.1 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a informačním videu.
Byl aktualizován seznam 500 nejvýkonnějších superpočítačů na světě TOP500. Nejvýkonnějším superpočítačem zůstává El Capitan od HPE (Cray) s výkonem 1,809 exaFLOPS. Druhý Frontier má výkon 1,353 exaFLOPS. Třetí Aurora má výkon 1,012 exaFLOPS. Nejvýkonnější superpočítač v Evropě JUPITER Booster s výkonem 1,000 exaFLOPS je na čtvrtém místě. Nejvýkonnější český superpočítač C24 klesl na 192. místo. Karolina, GPU partition klesla na 224. místo a Karolina, CPU partition na 450. místo. Další přehledy a statistiky na stránkách projektu.
Microsoft představil Azure Cobalt 200, tj. svůj vlastní SoC (System-on-Chip) postavený na ARM a optimalizovaný pro cloud.
Co způsobilo včerejší nejhorší výpadek Cloudflare od roku 2019? Nebyl to kybernetický útok. Vše začalo změnou oprávnění v jednom z databázových systémů a pokračovalo vygenerováním problém způsobujícího konfiguračního souboru a jeho distribucí na všechny počítače Cloudflare. Podrobně v příspěvku na blogu Cloudflare.
Byla vydána (Mastodon, 𝕏) první RC verze GIMPu 3.2. Přehled novinek v oznámení o vydání. Podrobně v souboru NEWS na GitLabu.
Eugen Rochko, zakladatel Mastodonu, tj. sociální sítě, která není na prodej, oznámil, že po téměř 10 letech odstupuje z pozice CEO a převádí vlastnictví ochranné známky a dalších aktiv na neziskovou organizaci Mastodon.
Byla vydána nová major verze 5.0 svobodného 3D softwaru Blender. Přehled novinek i s náhledy a videi v obsáhlých poznámkách k vydání. Videopředstavení na YouTube.
Ahoj, mám dotaz ohledně jednoduchého problému. V TCP každý accept() vytváří na straně serveru nové spojení, které má stále stejnou místní adresu i port. Dá se něčeho podobného docílit na straně klienta?
Úkol je jednoduchý: Démon, který (zejména kvůli firewallu) bude přijímat i navazovat TCP spojení pořád ze stejného portu. Každý démon může chtít navázat spojení (paralelně) s několika dalšími, případně přijmout několik příchozích spojení.
Strinktně vzato, TCP spojení je čtveřice (adresa, port, adresa, port). Proto si myslím, že by neměl být problém z jedné adresy a z jednoho portu navázat víc spojení, pokud se každé z nic aspoň v jednom prvku čtveřice odlišuje. Na Linuxu tohle bez problémů funguje, ale na Solarisu ne.
Například tato (pokusná) inicializace na Linuxu projde zcela bez problémů:
sock1 = socket( AF_INET6, SOCK_STREAM, IPPROTO_TCP ); sock2 = socket( AF_INET6, SOCK_STREAM, IPPROTO_TCP ); setsockopt( sock1, SOL_SOCKET, SO_REUSEADDR, &ONE, sizeof( ONE ) ); setsockopt( sock2, SOL_SOCKET, SO_REUSEADDR, &ONE, sizeof( ONE ) ); bind( sock1, (const struct sockaddr *) &addr, sizeof( addr ) ); bind( sock2, (const struct sockaddr *) &addr, sizeof( addr ) );
Pak lze bez problémů vytvořit dvě TCP spojení z téže adresy a z téhož portu ke dvěma různým strojům. To jsem důkladně otestoval. Oba sockety můžou odesílat i přijímat data, všechno se správně doručí a prostě to funguje.
Nicméně na Solarisu nastal problém. (Ne že bych to nečekal...) Druhý bind() mi hlásí Address already in use. Vždyť jsem přece nastavil SO_REUSEADDR, tak v čem je chyba? Taky jsem zkoušel nastavit setsockopt() až po prvním bind(), ale nepomolo to.
Solaris měl kdysi bug, který byl nejspíš odstraněn natolik radikálně, že SO_REUSEADDR už prostě nefunguje. Nebo možná funguje, ale neumožňuje vícenásobný bind() na in6addr_any? Možná, ale pak je tahle vymoženost pro mě bezcenná.
Nejdůležitější otázka nakonec: Nemá se náhodou problém tohoto typu řešit nějak jinak? Připadá mi, že každý systém si vykládá SO_REUSEADDR po svém. Pak tudy cesta nevede, protože takový kód není přenositelný.
Aha, tak možná je opravdu problém s tou wildcard adresou. Linuxu to kupodivu nevadí, zatímco Solarisu ano. Solaris tedy zřejmě neumí navázat několik TCP spojení ze stejné adresy a stejného portu. Nebo jsem něco přehlédl?
Tak tohle vypadá dost beznadějně. Někdo už tenhle problém řešil. A nejspíš nevyřešil. 
Vzdávám to. Když i Jabber provozuje serverová spojení z náhodných portů, asi to má svůj důvod...
[root@charon andrej]# netstat -atpn | grep 5269
tcp 0 0 :::5269 :::* LISTEN 6081/java
tcp 0 0 ::ffff:95.82.129.:39267 ::ffff:62.109.141.:5269 ESTABLISHED 6081/java
tcp 0 0 ::ffff:95.82.129.:54748 ::ffff:81.2.199.30:5269 ESTABLISHED 6081/java
tcp 0 0 ::ffff:95.82.129.1:5269 ::ffff:88.86.102.:46082 ESTABLISHED 6081/java
tcp 0 0 ::ffff:95.82.129.1:5269 ::ffff:81.2.199.3:57781 ESTABLISHED 6081/java
tcp 0 0 ::ffff:95.82.129.:38551 ::ffff:88.86.102.5:5269 ESTABLISHED 6081/java
tcp 0 0 ::ffff:95.82.129.1:5269 ::ffff:208.68.163:45581 ESTABLISHED 6081/java
tcp 0 0 ::ffff:95.82.129.:52673 ::ffff:208.68.163.:5269 ESTABLISHED 6081/java
Ten zvláštní multicasting, který jsem chtěl, by sice na Linuxu fungoval, ale to je chabá útěcha. Asi se budu muset vybodnout na ohleduplnost vůči firewallu a taky používat implicitní porty.
Ach jo, zase další den času v háji. 
Tiskni
Sdílej: