Конечно, он лично ничего не изобретал. Написал же, "заслуга как руководителя". Вот предыдущие руководители не добивались от сотрудников следования нормам и пошли аварии на старте, а этот - добился. Молодец, чо.
Великих достижений не было, но, хотя бы, порядок навёл.
>вообще в подобных компаниях типа 30+ лет проработал, начиная с времен bbn, как-то лучше привык думать :)
Ну это ж несложно увидеть, пресс-релизы посмотреть корпоративные...
>, интересно бы понять какую именно задачу Задачу "без потерь и с малыми задержками доставлять массивный (типа видео или бэкапов)" контент по быстрым абонентским линиям плохого качества. По мне, так сомнительной полезности затея.
Объективно говоря, безаварийность пусков Роскосмоса - это заслуга Рогозина как руководителя. Перед его приходом с этим была большая проблема, он добился персонала её устранения. Но это всё не имеет отношения к теме - технологии Роскосмоса - это технологии Роскосмоса, а в случае IPv17 мы видим сторонний прожект.
Хуавэй сначала сделал полноценную реализацию классического стека в своём железе и поработал с ней десяток с лишним лет, а тут подобного не наблюдается.
Никто б не ржал, если бы ребята со своим стартапом пошли туда, где на такое деньги штатно дают - в РФФИ, РВК или ФРИИ, например. Но они тем кто штатно такими вопросами занимаются не смогли доказать свою состоятельность (или не захотели) и сразу отправились к начальству. Так себе ход...
В 2017 могло бы быть интересно, если проект довести до ума. Подобные компании скупают подобные стартапы квадратно-гнездовым методом. В надежде что один из десяти выстрелит, или что они они перенесут какую-то ключевую особенность купленного продукта в свои.
Будет ли интересно сейчас - я не знаю, надо бы снова вникать (но мне за это сейчас вряд ли заплатят). Но 7 лет прошло - а продукта даже в бете так и нет. Что вызывает вопросы о состоятельности команды.
На приведённом фрагменте они пишут о том, что сетевое приложение (в смысле - реализация протокола) могло бы подстраивать особенность передачи своих данных под глюки канала, но их (разработчиков IPv17) понимание логики работы стека протоколов OSI мешает реализации такого подхода.
Но дальше они пишут, что индустрия такое, при этом всё-таки делает, а способ которым в других разработках делается, разработчикам IPv17 не нравится.
Собственно это о том, что при передаче TCP-пакетов можно было бы учитывать то, как глючит канал передачи данных на каждом из участков.
По мне, так это один из примеров той самой некачественной и манипулятивной документации, о которой я писал. Формально они всё правильно написали, фактически - непонятно зачем вообще это было писать. OSI - это всего лишь объяснительная модель, а не священная скрижаль, стек TCP/IP не имеет с ней однозначного соответствия. То, что решение некоей задачи достигается в полном соответствии именно с моделью OSI, а не как-то ещё, само по себе особого преимущества не даёт.
Ну они типа обозначили проблему (не факт, что это проблема), и типа предложили её решение.
Фишка IPv17 состоит в том, что они (якобы, в руках не держал, только документы читал) умеют оптимально реагировать на проблемы в канале и обеспечивают одновременно быстрое восстановление передачи и гарантированную доставку.
Это полезно в очень узких случаях, при передаче данных с камеры того же дрона это было бы спорным решением (возможно, для управления было бы оптимальнее получать помеху в передаче, а дальше снова актуальное видео, а не досылать полное видео с отставанием от актуальной картинки). Ну вот при онлайн-бэкапе - да, нужно именно так поступать. Но это все кмк не повод лезть к президенту со своей гениальной идеей.
Инвестор российский, институциональный с госучастием.
Они штатно проводили акции по раздаче денег, эти люди к ним зашли и дали свой проект на рассмотрение.
В этой ситуации я выступил в качестве эксперта за деньги (рекомендовал не инвестировать в проект без, как минимум, коренной переделки документации - у меня к этому проекту во всех его аспектах - и в техническом и финансовом был целый ряд неприятных вопросов), а так я в то время, в основном, работал приходящим IT-директором в разных проектах.
В декабре 2016-январе 2017 я писал рецензию на заявку этих парней для потенциального венчурного инвестора.
В то время та же самая технология у них была (якобы) оптимизирована вовсе не для беспилотников, а для пакетной доставки больших объёмов однородного контента (CDN, online-backup, VDI) по каналам с относительно плохим качеством связи. Типа говеного LTE. Прототипы у них уже тогда были, продукта не было, нормального финплана не было.
И вряд ли что-то концептуально поменялось за это время. Абы поменялось - продались бы стратегу давно.
Из этой штуки в калифорнийской долине можно было бы сделать, наверное, какой-то небольшой стартап и продать его кому-то из грандов индустрии типа Cisco, после чего он оказался бы захоронен где-то в недрах продуктовой линейки, как с такими проектами обычно и бывает.
Разумеется, ни о какой замене TCP этой технологией речи идти не может, это недоделанный нишевой продукт неясной степени полезности и с заявленными (тогда), но не реализованными сомнительными техническими особенностями - типа подписывания надёжной ЭЦП каждого пакета (три раза ха) и специфическим нестандартным протоколом маршрутизации, предложенным из непонятных соображений.
Качество документации было плохое, с попытками манипулировать терминами, вводя в заблуждение читателей.
За 7 лет, конечно, что-то могло и поменяться. Но вряд ли существенно, при таких-то подходах к запуску проекта.
Это не совсем верно. В атмосфере на постоянной основе присутствует от 0.2 до 0.5% водяного пара, и его доля за период наблюдений с середины XX непрерывно растёт. При этом превращение пара в дождь сопряжено с образованием облаков, а по результатам пролета самолёта облака обычно не образуются. Да и в целом, судьба водяного пара, возникшего, напомню, при сгорании при температуре около 3000 градусов вовсе не так однозначна, как Вы написали. Скорее, он будет плавно рассеиваться, постепенно повышая общую концентрацию пара в атмосфере, т.к. горячие струи пара имеют больше шансов на разлёт, чем на конденсацию.
Так что можно говорить о том, что высоколетящий самолёт с реактивным двигателем двигателем на водороде - это прям идеальная затея для техногенной провокации парникового эффекта. Слабенькой, конечно. Но заявляемой создателями цели борьбы с этим эффектом затея явно не отвечает.
>над созданием технологий более чистого топлива, такого как водород, который при сгорании производит водяной пар вместо углекислого газа.
Клоунада корпоративного масштаба. Температура горения водорода в атмосфере - около 3000 градусов, начиная с 2000 в реакцию начинает вовлекаться азот с дальнейшем образованием закиси азота N2O.
Но лох - не мамонт, лох не вымрет. Денег на передовую разработку дадут. А лет через 10 никто про эти обещания и не вспомнит.
"...Закись азота является третьим по значимости долгоживущим парниковым газом, накопление которого в атмосфере Земли — одна из причин глобального потепления, так как N2O является веществом, разрушающим стратосферный озон[2]..."
>>Второй случай - это вклинивание такой аппаратуры в уже работающей канал связи. Т.е. работа "нештатного" злоумышленника. "
>- в этом прелесть КРК, протокол позволяет измерять уровень ошибок, а значит при наличии евы, ее вмешательство будет измерено и процедура КРК будет прервана
Мы, напомню, обсуждали сценарии MiTM c двумя комплектами аппаратуры.
>Никакая индикация прослушивания не нужна, звонок на скомпрометированных ключах не начнется.
В таких сценариях ключи скомпрометированы не будут, каждому из атакуемых абонентов будет подставлен парный комплект аппаратуры, который будет вполне корректно отрабатывать КРК.
>"частую перегенерацию." - блестящая мысль, но блин ключь невозможно перегенерирвоать в принципе
Инфотекс в своих материалах утверждает прямо противоположное.
Они там, к слову, заявили, что канал по которому идёт КРК аутентифицируется, но не указали конкретно как и не ясно, хватит ли этого в обсуждаемых сценариях. Судя по оговоренной возможности компрометации сети в момент развёртывания, не хватит, как минимум, для первого из них.
Без общего секрета мы можем использовать для аутентификации ЭЦП. Понятно, что дальше встаёт вопрос об инфраструктуре доверия как таковой, но, технически, эта задача вполне решаема.
Конечно, он лично ничего не изобретал. Написал же, "заслуга как руководителя". Вот предыдущие руководители не добивались от сотрудников следования нормам и пошли аварии на старте, а этот - добился. Молодец, чо.
Великих достижений не было, но, хотя бы, порядок навёл.
Ребята решили пойти неверной тропой MS+Skype, слив свою абонентскую базу.
>вообще в подобных компаниях типа 30+ лет проработал, начиная с времен bbn, как-то лучше привык думать :)
Ну это ж несложно увидеть, пресс-релизы посмотреть корпоративные...
>, интересно бы понять какую именно задачу
Задачу "без потерь и с малыми задержками доставлять массивный (типа видео или бэкапов)" контент по быстрым абонентским линиям плохого качества.
По мне, так сомнительной полезности затея.
Объективно говоря, безаварийность пусков Роскосмоса - это заслуга Рогозина как руководителя. Перед его приходом с этим была большая проблема, он добился персонала её устранения. Но это всё не имеет отношения к теме - технологии Роскосмоса - это технологии Роскосмоса, а в случае IPv17 мы видим сторонний прожект.
Хуавэй сначала сделал полноценную реализацию классического стека в своём железе и поработал с ней десяток с лишним лет, а тут подобного не наблюдается.
Никто б не ржал, если бы ребята со своим стартапом пошли туда, где на такое деньги штатно дают - в РФФИ, РВК или ФРИИ, например. Но они тем кто штатно такими вопросами занимаются не смогли доказать свою состоятельность (или не захотели) и сразу отправились к начальству. Так себе ход...
Это - одна ситуация. Фил, я ж в чатике писал подробности.
>IPv17 сдох прямо очень давно не родившись
...и восстал из могилы. Как и положено нежити, получившийся из неродившихся младенцев, выглядит инфернально
Замена SS7 чем-то более вменяемым - это недостижимая мечта.
>настолько, насколько это возможно
Это ключевое. Индустрия на этот подход, в основном, подзабила, решила, что не нужно это всё так делать.
>думаете для Cisco могло быть интересно?
В 2017 могло бы быть интересно, если проект довести до ума. Подобные компании скупают подобные стартапы квадратно-гнездовым методом. В надежде что один из десяти выстрелит, или что они они перенесут какую-то ключевую особенность купленного продукта в свои.
Будет ли интересно сейчас - я не знаю, надо бы снова вникать (но мне за это сейчас вряд ли заплатят). Но 7 лет прошло - а продукта даже в бете так и нет. Что вызывает вопросы о состоятельности команды.
На приведённом фрагменте они пишут о том, что сетевое приложение (в смысле - реализация протокола) могло бы подстраивать особенность передачи своих данных под глюки канала, но их (разработчиков IPv17) понимание логики работы стека протоколов OSI мешает реализации такого подхода.
Но дальше они пишут, что индустрия такое, при этом всё-таки делает, а способ которым в других разработках делается, разработчикам IPv17 не нравится.
Собственно это о том, что при передаче TCP-пакетов можно было бы учитывать то, как глючит канал передачи данных на каждом из участков.
По мне, так это один из примеров той самой некачественной и манипулятивной документации, о которой я писал. Формально они всё правильно написали, фактически - непонятно зачем вообще это было писать. OSI - это всего лишь объяснительная модель, а не священная скрижаль, стек TCP/IP не имеет с ней однозначного соответствия. То, что решение некоей задачи достигается в полном соответствии именно с моделью OSI, а не как-то ещё, само по себе особого преимущества не даёт.
Ну они типа обозначили проблему (не факт, что это проблема), и типа предложили её решение.
Фишка IPv17 состоит в том, что они (якобы, в руках не держал, только документы читал) умеют оптимально реагировать на проблемы в канале и обеспечивают одновременно быстрое восстановление передачи и гарантированную доставку.
Это полезно в очень узких случаях, при передаче данных с камеры того же дрона это было бы спорным решением (возможно, для управления было бы оптимальнее получать помеху в передаче, а дальше снова актуальное видео, а не досылать полное видео с отставанием от актуальной картинки). Ну вот при онлайн-бэкапе - да, нужно именно так поступать. Но это все кмк не повод лезть к президенту со своей гениальной идеей.
Существует
Инвестор российский, институциональный с госучастием.
Они штатно проводили акции по раздаче денег, эти люди к ним зашли и дали свой проект на рассмотрение.
В этой ситуации я выступил в качестве эксперта за деньги (рекомендовал не инвестировать в проект без, как минимум, коренной переделки документации - у меня к этому проекту во всех его аспектах - и в техническом и финансовом был целый ряд неприятных вопросов), а так я в то время, в основном, работал приходящим IT-директором в разных проектах.
Ещё раньше. См ниже мою реплику. На момент попадания этой штуки ко мне на отзыв, она по всем признакам жила не меньше года-полутора как проект.
В декабре 2016-январе 2017 я писал рецензию на заявку этих парней для потенциального венчурного инвестора.
В то время та же самая технология у них была (якобы) оптимизирована вовсе не для беспилотников, а для пакетной доставки больших объёмов однородного контента (CDN, online-backup, VDI) по каналам с относительно плохим качеством связи. Типа говеного LTE. Прототипы у них уже тогда были, продукта не было, нормального финплана не было.
И вряд ли что-то концептуально поменялось за это время. Абы поменялось - продались бы стратегу давно.
Из этой штуки в калифорнийской долине можно было бы сделать, наверное, какой-то небольшой стартап и продать его кому-то из грандов индустрии типа Cisco, после чего он оказался бы захоронен где-то в недрах продуктовой линейки, как с такими проектами обычно и бывает.
Разумеется, ни о какой замене TCP этой технологией речи идти не может, это недоделанный нишевой продукт неясной степени полезности и с заявленными (тогда), но не реализованными сомнительными техническими особенностями - типа подписывания надёжной ЭЦП каждого пакета (три раза ха) и специфическим нестандартным протоколом маршрутизации, предложенным из непонятных соображений.
Качество документации было плохое, с попытками манипулировать терминами, вводя в заблуждение читателей.
За 7 лет, конечно, что-то могло и поменяться. Но вряд ли существенно, при таких-то подходах к запуску проекта.
Проходят десятилетия, а новые версии Винды всё также медленнее, чем старые.
Под грохот маркетинга о том, как всё ускорено.
Это не совсем верно. В атмосфере на постоянной основе присутствует от 0.2 до 0.5% водяного пара, и его доля за период наблюдений с середины XX непрерывно растёт. При этом превращение пара в дождь сопряжено с образованием облаков, а по результатам пролета самолёта облака обычно не образуются. Да и в целом, судьба водяного пара, возникшего, напомню, при сгорании при температуре около 3000 градусов вовсе не так однозначна, как Вы написали. Скорее, он будет плавно рассеиваться, постепенно повышая общую концентрацию пара в атмосфере, т.к. горячие струи пара имеют больше шансов на разлёт, чем на конденсацию.
Так что можно говорить о том, что высоколетящий самолёт с реактивным двигателем двигателем на водороде - это прям идеальная затея для техногенной провокации парникового эффекта. Слабенькой, конечно. Но заявляемой создателями цели борьбы с этим эффектом затея явно не отвечает.
Это я ещё не вспомнил, что водяной пар - тоже парниковый газ. Экий попил...
>над созданием технологий более чистого топлива, такого как водород,
который при сгорании производит водяной пар вместо углекислого газа.
Клоунада корпоративного масштаба. Температура горения водорода в атмосфере - около 3000 градусов, начиная с 2000 в реакцию начинает вовлекаться азот с дальнейшем образованием закиси азота N2O.
Но лох - не мамонт, лох не вымрет. Денег на передовую разработку дадут. А лет через 10 никто про эти обещания и не вспомнит.
"...Закись азота является третьим по значимости долгоживущим парниковым газом, накопление которого в атмосфере Земли — одна из причин глобального потепления, так как N2O является веществом, разрушающим стратосферный озон[2]..."
Воздержусь от спора. Устал.
>>Второй случай - это вклинивание такой аппаратуры в уже работающей канал связи. Т.е. работа "нештатного" злоумышленника. "
>- в этом прелесть КРК, протокол позволяет измерять уровень ошибок, а значит при наличии евы, ее вмешательство будет измерено и процедура КРК будет прервана
Мы, напомню, обсуждали сценарии MiTM c двумя комплектами аппаратуры.
>Никакая индикация прослушивания не нужна, звонок на скомпрометированных ключах не начнется.
В таких сценариях ключи скомпрометированы не будут, каждому из атакуемых абонентов будет подставлен парный комплект аппаратуры, который будет вполне корректно отрабатывать КРК.
>"частую перегенерацию." - блестящая мысль, но блин ключь невозможно перегенерирвоать в принципе
Инфотекс в своих материалах утверждает прямо противоположное.
Например, вот здесь:
https://infotecstechfest.ru/upload/iblock/38b/38b22597d931a2314898f7e2f24c9ee3.pdf
Они там, к слову, заявили, что канал по которому идёт КРК аутентифицируется, но не указали конкретно как и не ясно, хватит ли этого в обсуждаемых сценариях. Судя по оговоренной возможности компрометации сети в момент развёртывания, не хватит, как минимум, для первого из них.
Без общего секрета мы можем использовать для аутентификации ЭЦП. Понятно, что дальше встаёт вопрос об инфраструктуре доверия как таковой, но, технически, эта задача вполне решаема.