Думаю, за полгода система уже прошла обкатку. Собран фидбек.
Планируется ли продолжение цикла статей про ваш процессинг? Где можно будет подробно почитать почему делали так, какие проблемы пришлось решить, в каких местах выбранные инструменты подвели. Что удалось очень хорошо, где инструмент вас выручил.
Интересная статья.
Думаю, многим будет интересно "потыкать" проект. Но для тех, кто go не собирал поначалу может быть сложно. Можно собрать проект под разные системы (благо в go кросс-компиляция несложная) и положить статическим бинарен на GitHub. Или в крайнем случае — Docker образ. Так они смогут его скачать и запустить, а вы получить обширную обратную связь.
p2p мессерджер (кстати, есть ли русский синоним этому слову?).
Да. Мы в России его называем мессенджер :)
Если серьезно, то встречал разные, но "Система обмена мгновенными сообщениями" как-то сложно звучит, "болталка" — слишком несерьезно. Иногда встречал "чат", но это больше к виджету мессенджера, вставленному на сайт.
Так новый разработчик таким и выглядел по началу )
А дальше положил в GitHub необфусцированную хорошую версию, а в минифицированную сборку — с закладкой. Ведь никто не делает контрольную минификацию и сверку для проверки закладок.
если мой npm run dev начнет обфусцировать также 100500 зависимостей из node_modules, то хот-релоад начнет работать один раз в день.
Мне кажется нет ничего плохого, если код зависимостей будет собран один раз и потом минифициован и закеширован с привязкой к конкретной версии. Тогда хот-релоад своего кода не будет каждый раз пересобтрать зависимости. А если их версия изменилась, то еще раз собрать не проблемы.
Да, меня тоже смущает, что все сетевые уровни смешали в кучу. Поэтому будет сложно с роутерами и прочим. Роутер не должен ничего знать про вышележащие протоколы, а они не должны заниматься транспортом. Иначе придется делать софтверные роутеры на node.js, которые будут обновляться со скоростью обновления пакетов )
В "войне" с Телеграмом забанили почти 20 млн IP адресов — и ничего.
Причем Ростелеком до сих пор не успокоился — на сегодня остались заблокированными 3.8 млн адресов. Подробнее: https://usher2.club
Обоснований не будет — будет самая тупая и действенная блокировка по IP.
Только работать с такими переменными будет неудобно.
Далеко не каждый терминал позволяет удобно вводить их с клавы — значит нужно будет каждый раз Copy+Paste делать. Еще хуже ситуация — вы на маке, коллега на винде. У вас чуть разное отображение шрифтов и разный ввод символов. Брррр.
Не понимаю, зачем из нормального языка делать 1С.
Представьте идеальный мир, в котором врачи практически не ошибаются. Вот они лечат некоторое тяжелое заболевание, почти победили его — методика вылечивает 99% больных, а 1% умирает. Это успех или нет?
Для врачей это провал — этого 1% хватит, чтобы посадить всех врачей на планете в тюрьму. Теперь это уже неуспех для пациентов: был 1% неизлечимых — стало 100%.
Я даже не говорю про то как придти к такому успеху без экспериментальных методов по дороге.
Не очень понимаю, зачем все переносить на UDP?
Есть протокол SCTP — Stream Control Transmission Protocol, который как раз должен нормально подойти под этот вариант. В двух словах — "надежный UDP": протокол ориентированный на сообщения, с гарантией доставки, но без гарантии порядка. Вместо коннектов, есть ассоциации — фактически несколько одновременных коннектов через разные интерфейсы/адреса между хостами.
Для веб TCP дает слишком жесткие гарантии — гарантию порядка, которая вебу не нужна, но за которую приходится платить на плохих нестабильных сетях ненужными перепосылками, снижение скорости и пр.
Для веб не важно, в каком порядке загрузятся картинки на странице, важно, чтобы они все дошли.
Все же действительно, принцип работы другой. В TCP все идет от концепции потока данных. В SCTP от "сообщения". В общем, можно пересмотреть передачу данных по HTTP как набор сообщений — каждое сообщение отдельный ресурс (картинка, стиль, скрипт и пр.). Наверное, в этом есть здравый смысл. Как минимум на уровне нижележащего протокола не будет такой болью потеря и переупорядочивание пакетов. Ну заказали мы две картинки, они пришли нам в другом порядке — в чем проблема?
Где можно почитать подробнее про использование SCTP в проде?
Недавно хотел поэкспериментировать с ним, так в ряде языков даже не входит в стандартную либу.
Какие критерии рассматривали, когда выбирали язык для написания? Вы указали "безопасность работы с памятью, скорость, гонки", но наверное есть еще? Наличие разработчиков? Предыдущие наработки? Жесткое/мягкое время?
Рассматривалась ли, например, Scala? Язык во многом похож на Rust:
компилируемый (в байт-код JVM)
такая же типобезопасность,
статическая типизация с генериками
безопасная работа с памятью
аналогичные Option, Result, match.
Плюс функциональный язык, что так же помогает писать надежный код в ситуациях гонок.
При этом Scala хорошо принимается в финансовом мире, ее активно используют в банках. JVM — стандарт де-факто.
Вот пишут, что Waves сделали блокчейн на Scala всего в ~20К строк (в коде bitcoin примерно 100К строк).
Если не секрет, сколько у вас получилось строк?
Да ладно Сибирь. В Москве позапрошлом году был ледяной дождь, и обледенел контактный провод. Скоростные "Ласточки" не могли ездить — их таскали маневровые тепловозы. Вместо 15 минут ехали больше получаса.
Думаю, за полгода система уже прошла обкатку. Собран фидбек.
Планируется ли продолжение цикла статей про ваш процессинг? Где можно будет подробно почитать почему делали так, какие проблемы пришлось решить, в каких местах выбранные инструменты подвели. Что удалось очень хорошо, где инструмент вас выручил.
Интересная статья.
Думаю, многим будет интересно "потыкать" проект. Но для тех, кто go не собирал поначалу может быть сложно. Можно собрать проект под разные системы (благо в go кросс-компиляция несложная) и положить статическим бинарен на GitHub. Или в крайнем случае — Docker образ. Так они смогут его скачать и запустить, а вы получить обширную обратную связь.
Да. Мы в России его называем мессенджер :)
Если серьезно, то встречал разные, но "Система обмена мгновенными сообщениями" как-то сложно звучит, "болталка" — слишком несерьезно. Иногда встречал "чат", но это больше к виджету мессенджера, вставленному на сайт.
И… он моментально попадает блок-лист РКН )
После чего доступ к нему по IP заблокирован
Так новый разработчик таким и выглядел по началу )
А дальше положил в GitHub необфусцированную хорошую версию, а в минифицированную сборку — с закладкой. Ведь никто не делает контрольную минификацию и сверку для проверки закладок.
Мне кажется нет ничего плохого, если код зависимостей будет собран один раз и потом минифициован и закеширован с привязкой к конкретной версии. Тогда хот-релоад своего кода не будет каждый раз пересобтрать зависимости. А если их версия изменилась, то еще раз собрать не проблемы.
Да, меня тоже смущает, что все сетевые уровни смешали в кучу. Поэтому будет сложно с роутерами и прочим. Роутер не должен ничего знать про вышележащие протоколы, а они не должны заниматься транспортом. Иначе придется делать софтверные роутеры на node.js, которые будут обновляться со скоростью обновления пакетов )
В "войне" с Телеграмом забанили почти 20 млн IP адресов — и ничего.
Причем Ростелеком до сих пор не успокоился — на сегодня остались заблокированными 3.8 млн адресов. Подробнее: https://usher2.club
Обоснований не будет — будет самая тупая и действенная блокировка по IP.
Эти реализации как раз сильно разные и несовместимые.
Увы, негуловый quic-браузер я пока не видел.
Можно запустить локально и через ngrok пробросить себе вебхуки.
Только работать с такими переменными будет неудобно.
Далеко не каждый терминал позволяет удобно вводить их с клавы — значит нужно будет каждый раз Copy+Paste делать. Еще хуже ситуация — вы на маке, коллега на винде. У вас чуть разное отображение шрифтов и разный ввод символов. Брррр.
Не понимаю, зачем из нормального языка делать 1С.
Представьте идеальный мир, в котором врачи практически не ошибаются. Вот они лечат некоторое тяжелое заболевание, почти победили его — методика вылечивает 99% больных, а 1% умирает. Это успех или нет?
Для врачей это провал — этого 1% хватит, чтобы посадить всех врачей на планете в тюрьму. Теперь это уже неуспех для пациентов: был 1% неизлечимых — стало 100%.
Я даже не говорю про то как придти к такому успеху без экспериментальных методов по дороге.
Если есть желание поиграть с негугловым QUIC. Есть реализация без использования либ от хромиума https://github.com/lucas-clemente/quic-go
Пример эхо сервера и клиента — https://github.com/lucas-clemente/quic-go/blob/master/example/echo/echo.go
Вот где взять нормальный клиент, чтобы удобно смотреть? Chromium?
Версии 1.3, надеюсь? ;-)
Не очень понимаю, зачем все переносить на UDP?
Есть протокол SCTP — Stream Control Transmission Protocol, который как раз должен нормально подойти под этот вариант. В двух словах — "надежный UDP": протокол ориентированный на сообщения, с гарантией доставки, но без гарантии порядка. Вместо коннектов, есть ассоциации — фактически несколько одновременных коннектов через разные интерфейсы/адреса между хостами.
Для веб TCP дает слишком жесткие гарантии — гарантию порядка, которая вебу не нужна, но за которую приходится платить на плохих нестабильных сетях ненужными перепосылками, снижение скорости и пр.
Для веб не важно, в каком порядке загрузятся картинки на странице, важно, чтобы они все дошли.
Все же действительно, принцип работы другой. В TCP все идет от концепции потока данных. В SCTP от "сообщения". В общем, можно пересмотреть передачу данных по HTTP как набор сообщений — каждое сообщение отдельный ресурс (картинка, стиль, скрипт и пр.). Наверное, в этом есть здравый смысл. Как минимум на уровне нижележащего протокола не будет такой болью потеря и переупорядочивание пакетов. Ну заказали мы две картинки, они пришли нам в другом порядке — в чем проблема?
Где можно почитать подробнее про использование SCTP в проде?
Недавно хотел поэкспериментировать с ним, так в ряде языков даже не входит в стандартную либу.
В 2018 у всех нормальных банков есть чат техподдержки.
Думаю, это самый надежный вариант обращения:
А если у банка нет чата техподдержки — то нужен ли такой банк?
Какие критерии рассматривали, когда выбирали язык для написания? Вы указали "безопасность работы с памятью, скорость, гонки", но наверное есть еще? Наличие разработчиков? Предыдущие наработки? Жесткое/мягкое время?
Рассматривалась ли, например, Scala? Язык во многом похож на Rust:
Option,Result,match.Плюс функциональный язык, что так же помогает писать надежный код в ситуациях гонок.
При этом Scala хорошо принимается в финансовом мире, ее активно используют в банках. JVM — стандарт де-факто.
Вот пишут, что Waves сделали блокчейн на Scala всего в ~20К строк (в коде bitcoin примерно 100К строк).
Если не секрет, сколько у вас получилось строк?
Да ладно Сибирь. В Москве позапрошлом году был ледяной дождь, и обледенел контактный провод. Скоростные "Ласточки" не могли ездить — их таскали маневровые тепловозы. Вместо 15 минут ехали больше получаса.
И памятники танкам ВОВ тоже являются резервом на случай войны :)
Уже был такой случай — в ДНР сняли танк с постамента, расконсервировали и завели )