Ну почему сразу и агитка? Автор же не утверждает, что он тоже оптимист.
Думаю, эйфория, вызванная первоначальными успехами ИИ скоро пройдет. Маятник может качнуться и в другую сторону. И будут тогда заброшенные дата-центры стоять, как автомобильные заводы в Дейтройте.
Да, с развитием кластеризации и распараллеливания потребность в таких монстрах снижается. Лучше с точки зрения надежности иметь несколько серверов помельче в кластере, чем один большой. Да и охлаждать его сложнее.
Но всё равно, иногда сервера с большим количеством слотов выпускаются:
Серверные материнки тоже не имеют достаточного количества слотов памяти, чтобы туда все 78 плашек запихнуть. Придется, как бы, 4-5 мамок приобретать. А это тоже будет недёшево. Плюсом еще десяток процессоров, корпуса под нестандартный форм-фактор, системы охлаждения, блоки питания с резервированием.
В розницу всё это будет стоить гораздо дороже $20000.
Когда МСЭ с SPI для NAT обрабатывает такой пакет, он открывает псевдосоединение, в котором ждёт в ответ Echo reply с того же адреса, на который через него прошёл Echo request.
Но когда мы юзаем tracert, нам не приходит Echo request с целевого хоста. Нам приходит Time Exceeded совсем с другого промежуточного хоста.
Как тогда шлюз узнает, что этот ICMP-ответ и куда нужно транслировать, а не отвергать?
... у двух разных соединений с этих двух разных машин в таблице соединений МСЭ были разные ICMP ID.
Это Вы с двух разных внутренних хостов пинговали один внешний. А если наоборот - с одного внутреннего хоста пинговать разные внешние? Как тогда внутренний хост узнаёт, от какого внешнего хоста какой ответ пришёл?
... ответ на тот самый вселенский вопрос о смысле жизни и всего остального ...
Но вот я тут подумал и понял, что не понимаю, как организован исходящий NAT для ICMP.
Раз портов в ICMP нет, то нужно опираться на какие-то другие характеристики пакета. Например на ID ICMP-пакета.
Но вот в статье https://habr.com/ru/companies/ruvds/articles/763600/#diy автор утверждает, что в Windows у всех ICMP-пакетов одинаковый ID. И как тогда не путается комп с Window, пингуя одновременно несколько внешних хостов?
То ли автор той статьи чего-то не понял, то ли не нашел реального механизма сопоставления.
Т.е. исходящий проброс будет открыт NAT на шлюзе для UDP, но обратно он будет пропускать и ICMP-ответы?
Но кое-что всё равно не ясно:
Вот послали мы UDP-пакет на некий IP на порт 33434. Но ответ при достижении TTL=0 придет совсем с другого IP.
Т.е., даже если включен на шлюзе Symmetric NAT или Adress Restricted NAT, то такой ICMP-ответ не будет сходу отброшен (как ответ для неизвестного вопрошающего), а сначала будет вскрыт, узнан порт исходящего UDP-соединения, адрес вопрошающего и ему туда ответ будет перенаправлен. Правильно понимаю?
Это подпольная кличка командира Нортона :)
Надо было выйти на парковку или из лифта попробовать :D
Частная-то частная ... Но гос-во может вписаться за своего подопечного: "Это наша корова, и мы её доим". А другим забижать её не следует.
Так их уже несколько лет, как убирают. И 3G и 3.5G. Вроде как признали уязвимыми.
У нас в связи с этим были проблемы с передачей телеметрии через модемы, которые 2G не поддерживали, а в той местности 4G еще не было.
Оставят 2G, если где еще работают :)
Сегодня по SMS не пришел код подтверждения на выпуск сертификата ЭЦП. ОпСоС - МТС. Но на Теле-2 пришел.
Ограничения предназначены для того, чтобы было, чем прикрыть задницу: "Мы сделали всё, что могли - даже SMS-ки отменили".
Ну почему сразу и агитка? Автор же не утверждает, что он тоже оптимист.
Думаю, эйфория, вызванная первоначальными успехами ИИ скоро пройдет. Маятник может качнуться и в другую сторону. И будут тогда заброшенные дата-центры стоять, как автомобильные заводы в Дейтройте.
Читайте внимательно - это разные покупатели.
Один достал телефон и ушел.
А со вторым работали декораторы, он ушел, а доставку получил через Яндекс.
Так уже в 2014 году был случай. Правда, тогда - по делу. И после удаления материала о суициде доступ был восстановлен.
Да, с развитием кластеризации и распараллеливания потребность в таких монстрах снижается. Лучше с точки зрения надежности иметь несколько серверов помельче в кластере, чем один большой. Да и охлаждать его сложнее.
Но всё равно, иногда сервера с большим количеством слотов выпускаются:
https://3dnews.ru/1108212/gigabyte-vipustila-servernuyu-platu-r283zk0-standartnogo-razmera-2u-osnashchyonnuyu-48-slotami-dlya-operativnoy-pamyati-ddr5-rdimm?ysclid=moa8v6sl9a511276313
У нас есть один сервак с 32 слотами. Но используются пока что только 8 из них.
Серверные материнки тоже не имеют достаточного количества слотов памяти, чтобы туда все 78 плашек запихнуть. Придется, как бы, 4-5 мамок приобретать. А это тоже будет недёшево. Плюсом еще десяток процессоров, корпуса под нестандартный форм-фактор, системы охлаждения, блоки питания с резервированием.
В розницу всё это будет стоить гораздо дороже $20000.
Вот спёр то, что самому ему не нужно. Пока будет покупателя искать - цены упадут, а потом DDR4 ECC RDIMM вообще станет никому не интересна.
Нужно было сервер целиком выносить - больше шансов пристроить.
Но когда мы юзаем tracert, нам не приходит Echo request с целевого хоста. Нам приходит Time Exceeded совсем с другого промежуточного хоста.
Как тогда шлюз узнает, что этот ICMP-ответ и куда нужно транслировать, а не отвергать?
Это Вы с двух разных внутренних хостов пинговали один внешний. А если наоборот - с одного внутреннего хоста пинговать разные внешние? Как тогда внутренний хост узнаёт, от какого внешнего хоста какой ответ пришёл?
Неужели, "42"?
Спасибо. Это именно то, что я хотел уточнить.
Но вот я тут подумал и понял, что не понимаю, как организован исходящий NAT для ICMP.
Раз портов в ICMP нет, то нужно опираться на какие-то другие характеристики пакета. Например на ID ICMP-пакета.
Но вот в статье https://habr.com/ru/companies/ruvds/articles/763600/#diy автор утверждает, что в Windows у всех ICMP-пакетов одинаковый ID. И как тогда не путается комп с Window, пингуя одновременно несколько внешних хостов?
То ли автор той статьи чего-то не понял, то ли не нашел реального механизма сопоставления.
Ого!
Т.е. исходящий проброс будет открыт NAT на шлюзе для UDP, но обратно он будет пропускать и ICMP-ответы?
Но кое-что всё равно не ясно:
Вот послали мы UDP-пакет на некий IP на порт 33434. Но ответ при достижении TTL=0 придет совсем с другого IP.
Т.е., даже если включен на шлюзе Symmetric NAT или Adress Restricted NAT, то такой ICMP-ответ не будет сходу отброшен (как ответ для неизвестного вопрошающего), а сначала будет вскрыт, узнан порт исходящего UDP-соединения, адрес вопрошающего и ему туда ответ будет перенаправлен. Правильно понимаю?
Не совсем понятно, как будет проходить обратный ICMP-пакет через NAT?
Особенно, если на промежуточных роутерах включен Symmetric NAT или Port Restricted NAT или Adress Restricted NAT?
В оригинале, должно быть, просто 1 + O(1/logx). Так же как и Sum(O(1/a*loga)).
К сожалению, ссылка на оригинал у меня не открывается:
https://www.erdosproblems.com/forum/thread/1196
Машинный перевод?
В оригинале:
"Unit" следовало бы перевести как "узел", "блок", "элемент", а не "единица".
Но ИИ этого не знает.
На 10-20%? Если бы ...
Сегодня искал цены на Secure Net Studio 8 Постоянная защита (бессрочная лицензия).
В августе прошлого года она стоила 10500. Сейчас - 13125. Ровно на 25% подорожала.