Комментарии 29
Привет, Фидо. Я так по тебе скучал!
FREQ files
Эхх, проклятые капиталисты загубили городские телефонные сети. А ведь я еще не выкинул свой старенький IDC…
В современных реалиях не взлетит и работать не будет. Чтобы уронить нормальную работу фидонет достаточно прийти к одному-двум NC с постановлениями об (или даже без). Теоретические zmh нифига не работают irl, а нодлист с номерами телефонов нод — это такой метод борьбы за p2p-анонимность, видимо.
Конечно, не взлетит и не будет. Фидонет почему-то не роняли при всей его беззащитности. Знаете анекдот про Неуловимого Джо? Наш городской хаб находился где-то в ФАПСИ и всем было пофиг. Чекисты тоже были фидошниками.
А для анонимности и обмена секретами есть совсем другие технологии.
А для анонимности и обмена секретами есть совсем другие технологии.
С тех пор начали бороться с экстремизмом, незарегистрированными распространителями блог-информации посредством блог-техологий в обход блок-технологий роскомнадзора и прочие интересные вещи.
Я даже не про «обход», я про то, что такая конструкция имеет нулевую устойчивость, это раз, нулевую привлекательность (сравнить с джаббером, да?), два, и ничего, кроме ностальгии о временах, когда был сильно молодым и сильно бедным, не вызывает.
Я даже не про «обход», я про то, что такая конструкция имеет нулевую устойчивость, это раз, нулевую привлекательность (сравнить с джаббером, да?), два, и ничего, кроме ностальгии о временах, когда был сильно молодым и сильно бедным, не вызывает.
Критика ясна. Какие варианты решений?
Перестать бегать с технической частью FTN, имея в виду социальную.
Технологии FTN можно вспоминать крайне редко и в очень специальных случаях (например, докачку сообщений — чего не умеет делать ни один из современных протоколов, даже «email», хоть он и нифига не современный).
В остальном — пилить добротную распределённую систему с отказуемостью, избыточностью, шифрованием, p2p, mesh. Причём не на транспортном\сетевом уровнях (это уже сделали), а с поддержкой на прикладном уровне. Я до сих пор не вижу более-менее приличной замены эхам; со скрипом и матюгами из rss и torrent'ов собирается аналог файлэх.
По слухам tox многое решает — если под него начать писать остальное — может, и взлетит.
Технологии FTN можно вспоминать крайне редко и в очень специальных случаях (например, докачку сообщений — чего не умеет делать ни один из современных протоколов, даже «email», хоть он и нифига не современный).
В остальном — пилить добротную распределённую систему с отказуемостью, избыточностью, шифрованием, p2p, mesh. Причём не на транспортном\сетевом уровнях (это уже сделали), а с поддержкой на прикладном уровне. Я до сих пор не вижу более-менее приличной замены эхам; со скрипом и матюгами из rss и torrent'ов собирается аналог файлэх.
По слухам tox многое решает — если под него начать писать остальное — может, и взлетит.
Вот это уже интересней.
Я изначально это все планировал для комфортной работы в оффлайне и в условиях хреновой связи. Та самая докачка, да.
А вот как сделать добротную распределенную систему, где есть отказоустойчивость, избыточность, p2p, mesh на прикладном уровне, если на уровнях ниже их нет? Ну не предоставляет провайдер таких услуг. Даже VPN режет зачем-то. И TCP-сессии обрывает через 5 минут.
Для Таларии IP-сеть это всего лишь канал связи. Она может с тем же успехом обмениваться сообщениями через последовательный порт или хендл файла. Но если есть IP, то все проще. В сообщениях даже контрольной суммы нет — в IP они не нужны. Можно подключиться к любому узлу напрямую, зная его IP и порт.
Избыточность и отказоустойчивость заложены в протокол, нужно отладить детали. В шифровании и защите я слабо разбираюсь, пусть этим займутся спецы, мне нужно только предоставить возможности. p2p тоже заложен в принцип, а также возможен «внесетевой» p2p, как в SIP (где оговариваются только параметры соединения, а само соединение может идти даже по аналоговой линии). Mesh штука сложная, мне пока не под силу.
У TOX основная фишка — поиск контактов через DHT, то есть можно обойтись без DNS. Еще он умеет ретранслировать трафик на машинах с открытыми портами. Мне не нравится, что это как-то неочевидно происходит. В клиенте не отражено, в документации про это почти ничего нет. Анонимность и шифрование я оценить не могу, не силен.
Я изначально это все планировал для комфортной работы в оффлайне и в условиях хреновой связи. Та самая докачка, да.
А вот как сделать добротную распределенную систему, где есть отказоустойчивость, избыточность, p2p, mesh на прикладном уровне, если на уровнях ниже их нет? Ну не предоставляет провайдер таких услуг. Даже VPN режет зачем-то. И TCP-сессии обрывает через 5 минут.
Для Таларии IP-сеть это всего лишь канал связи. Она может с тем же успехом обмениваться сообщениями через последовательный порт или хендл файла. Но если есть IP, то все проще. В сообщениях даже контрольной суммы нет — в IP они не нужны. Можно подключиться к любому узлу напрямую, зная его IP и порт.
Избыточность и отказоустойчивость заложены в протокол, нужно отладить детали. В шифровании и защите я слабо разбираюсь, пусть этим займутся спецы, мне нужно только предоставить возможности. p2p тоже заложен в принцип, а также возможен «внесетевой» p2p, как в SIP (где оговариваются только параметры соединения, а само соединение может идти даже по аналоговой линии). Mesh штука сложная, мне пока не под силу.
У TOX основная фишка — поиск контактов через DHT, то есть можно обойтись без DNS. Еще он умеет ретранслировать трафик на машинах с открытыми портами. Мне не нравится, что это как-то неочевидно происходит. В клиенте не отражено, в документации про это почти ничего нет. Анонимность и шифрование я оценить не могу, не силен.
«Хреновая связь» — это очень сложное понятие.
Хреновая связь:
* толстый канал на марс с latency в десятки минут и потерей пакетов
* локальная сверхбыстрая сетка, которая рвёт физический коннтект каждые три секунды
* gps-канал, у которого может меняться ip каждую сессию, а сессии (в метро) меняются раз в 5 минут, а скорость ниже плинтуса.
И т.д.
Для кого-то хреновая связь — это 5 минут счастья раз в день (хороший канал), а потом ничего.
И под каждую эту штуку нужно своё.
По поводу фич. Если у нас два адресата не могут связаться напрямую, нужен релей. В обычных схемах для этого используется центральный узел, строящий маршрут и отдающий его нодам (фидо, типа). У узла либо аплинк на всё и вся, либо маршрутизация.
Есть bgp, когда каждый анонсирует свои маршруты и тех, кого он видит, а маршрутизаторы на основании анонсов от соседей строят таблицу маршрутизации. Всё равно централизовано, потому что номера as'ок выдаются registry, так же как и адреса.
Есть отлаженные штуки типа i2p, где у каждого свой хеш-адрес, который нельзя захватить без адского криптобрутфорса.
Но основное, куда надо копать (если мы про технические вкусняшки) — это в область децентрализованной маршрутизации, плюс протокол прикладного уровня, который бы из этого делал гарантированную доставку. И всё это в message-based формате, то есть с передачей не пакетов, а сообщений.
Если бы меня эта тема интересовала, я попробовал бы написать message-based версию TCP, которая бы могла работать в условиях недельных задержек и сообщений большого размера.
Маршрутизация в mesh-варианте — то ещё веселье…
Хреновая связь:
* толстый канал на марс с latency в десятки минут и потерей пакетов
* локальная сверхбыстрая сетка, которая рвёт физический коннтект каждые три секунды
* gps-канал, у которого может меняться ip каждую сессию, а сессии (в метро) меняются раз в 5 минут, а скорость ниже плинтуса.
И т.д.
Для кого-то хреновая связь — это 5 минут счастья раз в день (хороший канал), а потом ничего.
И под каждую эту штуку нужно своё.
По поводу фич. Если у нас два адресата не могут связаться напрямую, нужен релей. В обычных схемах для этого используется центральный узел, строящий маршрут и отдающий его нодам (фидо, типа). У узла либо аплинк на всё и вся, либо маршрутизация.
Есть bgp, когда каждый анонсирует свои маршруты и тех, кого он видит, а маршрутизаторы на основании анонсов от соседей строят таблицу маршрутизации. Всё равно централизовано, потому что номера as'ок выдаются registry, так же как и адреса.
Есть отлаженные штуки типа i2p, где у каждого свой хеш-адрес, который нельзя захватить без адского криптобрутфорса.
Но основное, куда надо копать (если мы про технические вкусняшки) — это в область децентрализованной маршрутизации, плюс протокол прикладного уровня, который бы из этого делал гарантированную доставку. И всё это в message-based формате, то есть с передачей не пакетов, а сообщений.
Если бы меня эта тема интересовала, я попробовал бы написать message-based версию TCP, которая бы могла работать в условиях недельных задержек и сообщений большого размера.
Маршрутизация в mesh-варианте — то ещё веселье…
Хреновая связь еще может означать необходимость ножками дойти до своего узла с дискеткой флешкой. Заодно и пива попить с сисопом.
TCP не может быть message-based, ибо оно сеансово-поточное по определению. Винт Серф вроде пытается что-то такое сотворить, удачи ему.
Вот по образу и подобию UDP еще можно что-то такое сделать между двумя узлами. То есть, опуститься до канального уровня. Мы получаем через канал некое крупное сообщение, лист бумаги. А выше (на сетевом уровне IP) оно как в шреддере режется на мелкие полоски по полтора килобайта без каких-либо маркеров и их хрен соберешь обратно в одно целое. Получается, нужно резать и маркировать сообщение заранее, еще до помещения в канальный уровень.
Делаю вывод, что отправить файл с фильмом на Марс через IP будет сложно, поскольку придется его порезать на мелкие части, в каждую добавить порядковый номер, контрольную сумму, избыточную информацию для восстановления. Плюс каждый уровень OSI добавит свои заголовки. В результате полезная нагрузка при прохождении через канал будет составлять лишь малую часть от объема передаваемых данных.
А если перенести нагрузку по обеспечению целостности и последовательности на канальный уровень (оно обычно уже есть на всех известных мне каналах), то сетевой уровень может взять на себя некоторые функции транспортного. В некоторых случаях ведь возможно использовать сеансовый уровень сразу поверх канального. Я хочу проверить это на практике. А еще можно использовать сеансовый уровень TCP-IP как канальный для DNMP, как это сейчас и сделано. Если сделать линк в виде обертки над TCP, которая будет сама переподключаться при обрывах и таймаутах, использовать одновременно несколько TCP-сессий, использовать какие-нибудь трюки типа регулирования размера пакета и задержек при отправке, то суммарная производительность такого линка будет значительно выше обычной TCP сессии. Это факт, так работают качалки и торренты.
Вот по образу и подобию UDP еще можно что-то такое сделать между двумя узлами. То есть, опуститься до канального уровня. Мы получаем через канал некое крупное сообщение, лист бумаги. А выше (на сетевом уровне IP) оно как в шреддере режется на мелкие полоски по полтора килобайта без каких-либо маркеров и их хрен соберешь обратно в одно целое. Получается, нужно резать и маркировать сообщение заранее, еще до помещения в канальный уровень.
Делаю вывод, что отправить файл с фильмом на Марс через IP будет сложно, поскольку придется его порезать на мелкие части, в каждую добавить порядковый номер, контрольную сумму, избыточную информацию для восстановления. Плюс каждый уровень OSI добавит свои заголовки. В результате полезная нагрузка при прохождении через канал будет составлять лишь малую часть от объема передаваемых данных.
А если перенести нагрузку по обеспечению целостности и последовательности на канальный уровень (оно обычно уже есть на всех известных мне каналах), то сетевой уровень может взять на себя некоторые функции транспортного. В некоторых случаях ведь возможно использовать сеансовый уровень сразу поверх канального. Я хочу проверить это на практике. А еще можно использовать сеансовый уровень TCP-IP как канальный для DNMP, как это сейчас и сделано. Если сделать линк в виде обертки над TCP, которая будет сама переподключаться при обрывах и таймаутах, использовать одновременно несколько TCP-сессий, использовать какие-нибудь трюки типа регулирования размера пакета и задержек при отправке, то суммарная производительность такого линка будет значительно выше обычной TCP сессии. Это факт, так работают качалки и торренты.
Вы не на то фокусируетесь. «Поточность» — дело десятое.
Я про метод аггрегации ack'ов, предсказания загрузки (число упреждающей отправки сообщений, размер окна), механизм с подтверждением получения сообщений и т.д.
Всё это надо переделывать в message-based transmission. Packet based каналы связи очень плохо приспособлены к задержкам в неделю.
Я про метод аггрегации ack'ов, предсказания загрузки (число упреждающей отправки сообщений, размер окна), механизм с подтверждением получения сообщений и т.д.
Всё это надо переделывать в message-based transmission. Packet based каналы связи очень плохо приспособлены к задержкам в неделю.
Как это сделать, если сообщения для уровня IP нужно пропустить через шреддер? Я думаю, что никак. Тюнингом TCP можно добиться улучшения скорости и/или отклика в пределах планеты. А передать большой массив корявых пакетов да еще с такой задержкой…
А если канал на Марс будет работать не на канальном (2-м) уровне, а на прикладном (7-м), то все элементарно. Берем из сети, к примеру, картинку с котиком. В подходящий момент через модем с наклейкой «Почта России» в сторону Марса излучается сообщение с достаточной избыточностью и защитой. Через неделю она прилетает покоцаная, но за счет избыточности и контрольных сумм данные можно восстановить. Дальше она идет в IP-сеть Марса, и марсианский хипстер лайкает земного котика. Других вариантов для IP я пока не вижу.
В спутниковом интернете ведь IP через MPEG-TS, и это жестоко. Потерялся пакетик из TCP-сессии — последующие пакеты забракованы, жди таймаута и еще 2 секунды на повторный запрос. И там часто используются http-прокси прикладного уровня, которые допускают прием поврежденных медиафайлов без перезапроса, а для чувствительных типов данных добавляют избыточности.
А если канал на Марс будет работать не на канальном (2-м) уровне, а на прикладном (7-м), то все элементарно. Берем из сети, к примеру, картинку с котиком. В подходящий момент через модем с наклейкой «Почта России» в сторону Марса излучается сообщение с достаточной избыточностью и защитой. Через неделю она прилетает покоцаная, но за счет избыточности и контрольных сумм данные можно восстановить. Дальше она идет в IP-сеть Марса, и марсианский хипстер лайкает земного котика. Других вариантов для IP я пока не вижу.
В спутниковом интернете ведь IP через MPEG-TS, и это жестоко. Потерялся пакетик из TCP-сессии — последующие пакеты забракованы, жди таймаута и еще 2 секунды на повторный запрос. И там часто используются http-прокси прикладного уровня, которые допускают прием поврежденных медиафайлов без перезапроса, а для чувствительных типов данных добавляют избыточности.
А откуда у вас вообще IP появился? Я говорю про реализацию принципов TCP для message-based сетей. Принцип простой: формируем сообщения (вместо IP), доставка сообщений по сети ненадёжная, хотя и избыточная. А дальше два клиента с помощью ACK'ов и контролируемого количества/размера бандлов обеспечивают гарантированную передачу сообщений из точки А в точку Б.
Для высоконадёжной системы с большими задержками пакетная передача данных будет работать плохо. Message-based — много лучше, особенно, если там будет локальная докачка в районе hop-to-hop.
Для высоконадёжной системы с большими задержками пакетная передача данных будет работать плохо. Message-based — много лучше, особенно, если там будет локальная докачка в районе hop-to-hop.
А, понял. ACK для сообщений делается элементарно — если в заголовке сообщения стоит параметр «требуется подтверждение», то получатель высылает подтверждение. Можно придумать вариации, когда подтверждения отправляет каждый транзитный узел. Можно начать передавать сообщение на следующий узел сразу после приема заголовка, не дожидаясь приема целиком. Вариантов много, это большое поле для исследований и экспериментов. Я это планирую сделать.
Но я предпочел бы, чтобы бОльшую часть вопросов передачи решали каналы между узлами. Им виднее, как лучше передавать в каждом конкретном случае — то сплошным потоком с минимумом подтверждений, то маленькими пакетами с перезапросами.
Но я предпочел бы, чтобы бОльшую часть вопросов передачи решали каналы между узлами. Им виднее, как лучше передавать в каждом конкретном случае — то сплошным потоком с минимумом подтверждений, то маленькими пакетами с перезапросами.
Оно делается-то элементарно, но если посмотреть на TCP — сплошная магия. В первую очередь потому, что надо понять, сколько упреждающе можно послать пакетов так, чтобы не перегрузить сеть, и когда надо начинать перепосыл (то есть считать потерянным).
Ни один вменяемый канальный или сетевой протокол не гарантирует доставки.
Ни один вменяемый канальный или сетевой протокол не гарантирует доставки.
В TCP магия только при передаче мелких пакетов по общим «трубам», вместе с кучей других пакетов. А между двумя точками никакой особой магии.
Я вот даже не знаю ни одного канального протокола (кроме Ethernet, который не вполне канальный) без контроля целостности и перепосылки битых блоков по умолчанию. Много канальных протоколов построено на базе HDLC, который по сути тот же TCP. Протоколам вышестоящих уровней даже приходится специально сигналить канальным протоколам, чтоб они пропускали битые блоки для некритичных к целостности данных. UDP Lite например.
Я вот даже не знаю ни одного канального протокола (кроме Ethernet, который не вполне канальный) без контроля целостности и перепосылки битых блоков по умолчанию. Много канальных протоколов построено на базе HDLC, который по сути тот же TCP. Протоколам вышестоящих уровней даже приходится специально сигналить канальным протоколам, чтоб они пропускали битые блоки для некритичных к целостности данных. UDP Lite например.
Да ладно, «никакой магии». Уж поверьте мне, я только чуть-чуть хлебнул этого, но не дай бог вам оказаться в ситуации, когда надо тюнить tcp. Я тюнил. На десятигигабитном L2 сегменте в 50км размером. Разница в производительности достигала 2 раза (в сравнении с дефолтными значениями) и раз 10-15 (вниз, худшая из попыток).
Дело в том, что в вашем описании оно всё peer-to-peer, а я про message-based неполносвязную mesh-сеть с линками разной надёжности и производительности.
Впрочем, ладно, сворачиваем дискуссию, ибо с моей стороны нет энтузиазма, а с вашей — желания делать то, что мне кажется правильным.
хм.
Дело в том, что в вашем описании оно всё peer-to-peer, а я про message-based неполносвязную mesh-сеть с линками разной надёжности и производительности.
Впрочем, ладно, сворачиваем дискуссию, ибо с моей стороны нет энтузиазма, а с вашей — желания делать то, что мне кажется правильным.
хм.
да фидо положить как раз легко, и некоторые не особо сознательные участники этим развлекались — например, хренакнуть 200+ мегов ююков через ip-линк. а потом в экстренном режиме чистили хабы r5020 пока оно дальше на модемные линки не уползло.
Голдед! Мои глаза — мои глаза!
Фидонет… Есть
Векторный… Читаем: «Векторная адресация.» Есть.
Гипертекст… Нет.
Вывод: не взлетит.
Шутка конечно, но взаправду сложно понять что такого эту штука может сейчас предложить.
Векторный… Читаем: «Векторная адресация.» Есть.
Гипертекст… Нет.
Вывод: не взлетит.
Шутка конечно, но взаправду сложно понять что такого эту штука может сейчас предложить.
Я видел этот пост без Мицгола в комментах.
Прошли сутки, а Мицгола все нет. Я начинаю за него беспокоится, ребят…
Какие пошли люди им предлагают какое-то решение, а они нос воротят. Может быть просто хорошую добрую FTN просто перетащили в Интернеты и теперь собирают с каждого из Вас немного денег, а при FTN такого не было и более того к любому ноду можно было обратиться и поговорить и спросить, а вы попробуйте обратитесь сейчас с SPB-IX. Впрочем разные философии в основе цель-стремическая и бабло-стремическая.
> Он стал по-настоящему кроссплатформенным (благодаря Lazarus), многое было переписано на свежую голову, реализовано несколько новых идей
> Так исторически сложилось и пока не нашлось веской причины это менять.
> Бинарники пока еще очень-очень сырые,
387 кб .pas, из которых часть комменты, 14340 строк кода.
Окей, назовем это эталонной реализацией, прототипом, как угодно; но продолжать на этом вашем FPC писать не надо, пожалуйста. Потом ведь на поддержке этого макаронного кода будете за голову хвататься.
Писать код на паскалеподобной среде с куцей стандартной библиотекой — это фричество. Еще б как плагин под Leechcraft это реализовали и сделали б поддержку twofish-шифрования всех проходящих станз.
P.S. Мицгол-то вообще фанат интерпретируемых языков, похоже, но реализация фидонета на паску… паскад… паскале и его должна была пронять :)
> Так исторически сложилось и пока не нашлось веской причины это менять.
> Бинарники пока еще очень-очень сырые,
387 кб .pas, из которых часть комменты, 14340 строк кода.
Окей, назовем это эталонной реализацией, прототипом, как угодно; но продолжать на этом вашем FPC писать не надо, пожалуйста. Потом ведь на поддержке этого макаронного кода будете за голову хвататься.
Писать код на паскалеподобной среде с куцей стандартной библиотекой — это фричество. Еще б как плагин под Leechcraft это реализовали и сделали б поддержку twofish-шифрования всех проходящих станз.
P.S. Мицгол-то вообще фанат интерпретируемых языков, похоже, но реализация фидонета на паску… паскад… паскале и его должна была пронять :)
И какой язык вы предлагаете? Сколько это сэкономит времени в дальнейшем? Пока никаких проблем с поддержкой и функциональностью не возникало. У меня есть и более сложные проекты, которые я спокойно развиваю и поддерживаю в одиночку. Единственное, с чем есть проблемы — это портирование на браузеры и на мобильные платформы. Но это проблема всех компилируемых языков, насколько мне известно. Появится транслятор в байт-код JVM и JS — проблема решится.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мессенджер на базе FTN-технологий