Тут начинается асимптотическое приближение, как к 0° К :)
Ну и немного (много?) маркетинга: когда дойдёт дело до серийной машины, всё может стать не так красиво.
Там, как я понимаю, экономический вопрос стоял где-то в последнем ряду; как и в лунной гонке, №1 — престиж.
Ни 144, ни Конкорд, ни B2707 экономически эффективными (принесшими прибыль) не были.
Я и с TCP наступал на похожее, только не у провайдера, а на MS TMG (мётрвая штука, но всё же вполне допустимый прецендент). Один абстрактный пакет данных не проходит вообще. Оказалось, совпал с сигнатурой какого-то вируса в его базе данных.
Мы экспериментальным путём обнаружили немного другое. После определённого периода (секунд 10-20) неиспользования канала данных, канал разрывается оператором где-то на нижнем (канальном?) уровне; при этом высшие уровни не информируются. Т.е. если было поднято TCP соединение, оно так и останется поднятым и неразорванным. При дальнейшей попытке использования канал восстанавливается (опять же, без сигнализации), на что уходит 5-10 секунд. То есть на уровне TCP, если передавать часто — отклик очень быстрый, но стоит немного задержаться — и получаем огромный лаг. Опять же, нет никакой гарантии, что восстановить канал удастся. В общем выходит так, что ориентироваться на сигнализацию в TCP нельзя, и быть уверенным в передаче, если соединение установилось — тоже нельзя; только ACK на уровне приложения!
Я почти уверен, что большинство мобильных сетей ведут себя подобным образом; различаются детали (период ожидания до разъединения и т.п.). Просто они же так экономят критический ресурс — ёмкость соты.
Про UDP, к сожалению, не знаю, но что-то мне подсказывает, что поведение может быть похожим: пока канал поднят, UDP будет пролетать; чуть задержались — UDP или будет теряться, или, как вы пишете, буферизоваться где-то в том месте, где управляется состояние канала.
Mars One, кстати, предлагал похожий подход.
Да, и пока база строится, уже можно начинать какие-то эксперименты, и даже производство; тот же ИТЭР активно развивает как раз такую робототехнику.
А ещё, крутая, и уже, наверное, не очень затратная (раз уж база строится) разведмиссия была бы — найти и вернуть американцам те самые Хассельблады :)
Ну вот «потому, что можем» — пахнет гонкой, а не реальными нуждами. Это мы уже проходили; дорого и не особо полезно.
Нерешаемые проблемы там тоже есть, просто другие. А вот не решаемые в условиях Земли, и решаемые там — да, есть. Извините, если придирадсь к словам.
Я к тому, что всё, кроме космопорта, на сегодня наверняка можно делать без участия человека. Это может сильно ускопить развёртывание базы, разве нет? Mars One, кстати, предлагал похожий подход.
Кстати, ещё одна связь с ИТЭР: там тоже очень активно развавается робототехника обслуживания.
Вроде бы техника уже вполне дошла (и Кьюриосити это демонстрирует); а стоит ли вообще отправлять пилотируемые миссии и создавать обитаемую базу? В отличие от Марса тут можно делать телеуправление в почти реальном времени!
По-настоящему WebAsm «полетит», как мне кажется, тогда, когда его не просто поддержат все браузеры, а когда закостенелый энтерпрайз обновится внутри до нужной версии IE (или того, на что они там перейдут).
JS неплохо минифицируется и достаточно шустро уже исполняется. Я не знаю как устроены современные JS-движки в браузерах, но не удивлюсь, если окажется, что внутри они на лету компилируют JS и исполняют его в виде байт-кода или вообще native-кода. Но, я согласен, это всё скорее просто из-за того, что «так заведено», или то самое «исторически сложившееся и уже окостеневшее», и нормальный с нуля разработанный под браузерные нужды байт-код конечно лучше.
Аномальная заинтересованность мне тоже необычна; возможно это связано с тем, что поддерживать JS с его «особенностями» всех уже так достало, что вовремя поднятый флаг привлёк всех :)
В JS по сравнению с другими языками их слишком много, как мне кажется.
JS должен стать языком кросс-компиляции из Java, Kotlin, Python, C# и т.п. Ну или WebAssembly, если взлетит. Тогда про его странности забудут все, кроме создателей кросс-компиляторов :)
Ну и немного (много?) маркетинга: когда дойдёт дело до серийной машины, всё может стать не так красиво.
Ни 144, ни Конкорд, ни B2707 экономически эффективными (принесшими прибыль) не были.
Я почти уверен, что большинство мобильных сетей ведут себя подобным образом; различаются детали (период ожидания до разъединения и т.п.). Просто они же так экономят критический ресурс — ёмкость соты.
Про UDP, к сожалению, не знаю, но что-то мне подсказывает, что поведение может быть похожим: пока канал поднят, UDP будет пролетать; чуть задержались — UDP или будет теряться, или, как вы пишете, буферизоваться где-то в том месте, где управляется состояние канала.
Да, и пока база строится, уже можно начинать какие-то эксперименты, и даже производство; тот же ИТЭР активно развивает как раз такую робототехнику.
А ещё, крутая, и уже, наверное, не очень затратная (раз уж база строится) разведмиссия была бы — найти и вернуть американцам те самые Хассельблады :)
Нерешаемые проблемы там тоже есть, просто другие. А вот не решаемые в условиях Земли, и решаемые там — да, есть. Извините, если придирадсь к словам.
Я к тому, что всё, кроме космопорта, на сегодня наверняка можно делать без участия человека. Это может сильно ускопить развёртывание базы, разве нет? Mars One, кстати, предлагал похожий подход.
Кстати, ещё одна связь с ИТЭР: там тоже очень активно развавается робототехника обслуживания.
JS неплохо минифицируется и достаточно шустро уже исполняется. Я не знаю как устроены современные JS-движки в браузерах, но не удивлюсь, если окажется, что внутри они на лету компилируют JS и исполняют его в виде байт-кода или вообще native-кода. Но, я согласен, это всё скорее просто из-за того, что «так заведено», или то самое «исторически сложившееся и уже окостеневшее», и нормальный с нуля разработанный под браузерные нужды байт-код конечно лучше.
Аномальная заинтересованность мне тоже необычна; возможно это связано с тем, что поддерживать JS с его «особенностями» всех уже так достало, что вовремя поднятый флаг привлёк всех :)
GWT помер, но, как мне кажется, идея была правильной.
JS должен стать языком кросс-компиляции из Java, Kotlin, Python, C# и т.п. Ну или WebAssembly, если взлетит. Тогда про его странности забудут все, кроме создателей кросс-компиляторов :)