Сабж.

Помню, что Денис эти 2 недели отсутствует, но всё-таки надо бы узнать, есть здесь кто или нет.

тест

я живой. раз 20 пытался сюда написать - да и сейчас еле залогинился. писал на @ii-net.tk, дали отлуп. писал на spline@ - нет ответа. других способов регистрации не нашёл. и только сейчас нашёл свой ключ.

дважды проезжал мимо Иркутска, но так и не смог закинуть сюда сообщение

> я живой.
Ура, есть люди! Привет :)

> раз 20 пытался сюда написать - да и сейчас еле залогинился. писал на @ii-net.tk, дали отлуп.
Разберусь с этим, спасибо за ответ.

> писал на spline@ - нет ответа.
Насколько помню, Андрей по выходным отдыхает.

Что у тебя хоть нового? Давно не заходил сюда.

> Ура, есть люди! Привет :)

Здраствуйте, друзья, кого видел или нет. :)

> Что у тебя хоть нового? Давно не заходил сюда.

я ж говорю - заходил :) но у вас тут закрытый клуб, что даже обладателю дома №2 по проспекту Мира - милиция на входе шлагбаум закрывает :)

вообще - хочется как-нибудь когда-нибудь всё же доделать свою сеть... но по-хорошему - надо как-то сделать совместимость между софтом. основное, что мне хочется от своего нового протокола - это короткие msgid (12 символов, а то и 8), избавление от цифровых приставок и возможность запрашивать произвольное количество сообщений (чтобы в одной эхе можно было хранить хоть миллион сообщений, но юзерам это не мешало жить). вариант с "api, которое умеет всё" я использовать не буду - в принципе, уже есть промежуточный вариант "ii12":

hg clone http://hg.51t.ru/ii12/

который использует старые url для запроса, но идентификаторы 12-символьные и эхи определяются не ЭХА.ЧИСЛО, а :ЭХА. полагаю, так всё можно и оставить, и подобную схему - научить понимать клиенты (кстати, а где ссылка со всеми актуальными клиентами?), для совместимости.

в общем, если есть интерес - давайте организуем конгресс по выработке стандартов взаимодействия сетей ii и gk11 (bosfor и uliss, как более трудоёмкие и навороченные сети - отменяются, gk11 - это тот же ii, но без технических недостатков: собственно, ii всегда была временным экспериментом, чтобы эти недостатки на практике выявить). такие сети должны жить, а не умирать в тишине :)

> кстати, а где ссылка со всеми актуальными клиентами

http://ii-net.tk/iidownload/
Всегда здесь было.

А насчёт остального утром отвечу, так как спать организму надо :)

Qt-клиент - это вот это?

https://github.com/vit1-irk/iicli-modular

> основное, что мне хочется от своего нового протокола - это короткие msgid (12 символов, а то и 8)
У нас куча клиентов, в них стоят проверки (хотя в сишном и qt они точно отсутствуют). Да и не особо это важно: было всегда 20 и не мешало.

> избавление от цифровых приставок и возможность запрашивать произвольное количество сообщений (чтобы в одной эхе можно было хранить хоть миллион сообщений, но юзерам это не мешало жить).
Теперь подробнее рассказывай, как ты будешь обеспечивать безболезненную жизнь с миллионом сообщений в эхе :)
Это же главная архитектурная проблема ii, если мы помним.

> в общем, если есть интерес - давайте организуем конгресс по выработке стандартов взаимодействия сетей ii и gk11
Написать гейт-скрипт, как было в прошлый раз с uliss - без проблем. Но менять стандарты у себя пока смысла не имеет.

> У нас куча клиентов, в них стоят проверки (хотя в сишном и qt они точно отсутствуют). Да и не особо это важно: было всегда 20 и не мешало.

просто тут 2 варианта:

1. делать форки всех клиентов - тогда будут одни и те же клиенты, но под разные сети
2. научить клиенты использовать оба стандарта

> Теперь подробнее рассказывай, как ты будешь обеспечивать безболезненную жизнь с миллионом сообщений в эхе :)

я уже писал об этом в bosfor - так же, как в nntp или в fido с rescan - забираем только последние n сообщений. либо количественно, либо отслеживаем новое поле таймштампа "прибыло на станцию" и отслеживаем по нему. в любом случае, клиент должен уметь изменять глубину запроса (нужны ли ему болталки за 10 лет), и после этого сообщения должны загружаться в правильном порядке.

собственно, всё это уже работает в bosfor, вроде и в ii12 это работает (не помню)

> Написать гейт-скрипт, как было в прошлый раз с uliss - без проблем. Но менять стандарты у себя пока смысла не имеет.

нужно выработать общие стандарты. тот же uliss не мог гейтовать любую эху. есть ещё нюансик с протоколами ии:// в ii и аналогичными для эх и сообщений... в общем, стандарты должны учитывать друг друга, чтобы легко меняться.

> Это же главная архитектурная проблема ii, если мы помним.

у ii не может быть архитектурных проблем, это была проба пира, набросанная за 20 минут "давайте мы вот так попробуем и покрутим, а потом сделаем, как надо". была бы нужда - были бы и iii, и iiii :), но вроде текущая реализация и достаточно простая, и полностью меня устраивает (есть даже нашмётки для NETMAIL, но это - после)


поэтому нужен симпозиум - чтобы не дублировать постоянно одно и то же, клонируя серверы и клиенты, а добиться совместимости

> 2. научить клиенты использовать оба стандарта
В моих клиентах проверок на длину msgid (и не только длину) нет. Есть только проверки на эху (если в строке есть точка, то это эха), но могу добавить двойной фильтр, если что.

> забираем только последние n сообщений. либо количественно,
Если на сервере за время до фетча появились сообщения в количестве больше n, то клиент не сможет их зафетчить.

> либо отслеживаем новое поле таймштампа "прибыло на станцию" и отслеживаем по нему.
Таймштамп ненадёжен тем, что как у клиента, так и у сервера системное время может быть неверным. Допустим, что оно верное, остаётся другая проблема: проблематичность отслеживания таймстампов для каждого сообщения, т.е. придётся либо строить кэш, либо завязываться полностью на базах данных, что убирает принцип простоты.

> нужно выработать общие стандарты. тот же uliss не мог гейтовать любую эху. есть ещё нюансик с протоколами ии:// в ii и аналогичными для эх и сообщений... в общем, стандарты должны учитывать друг друга, чтобы легко меняться.
> поэтому нужен симпозиум - чтобы не дублировать постоянно одно и то же, клонируя серверы и клиенты, а добиться совместимости

Давайте вырабатывать. Только в пределах разумного, конечно =)

> покажите хоть одну ноду с регистрацией, на случай потери ключа
Таких пока нет. Надо будет что-нибудь придумать.

> В моих клиентах проверок на длину msgid (и не только длину) нет. Есть только проверки на эху (если в строке есть точка, то это эха), но могу добавить двойной фильтр, если что.

человек может сменить сеть, и при этом захотеть сохранить архивы эх. дело не в длине, а в том, чтобы софт понимал, что это такое

> Если на сервере за время до фетча появились сообщения в количестве больше n, то клиент не сможет их зафетчить.

это организационнная проблема, а не техническая. кроме того, если в n сообщений нет ни одного знакомого, можно запросить ещё n, а потом ещё. в фидо тоже и сообщения терялись и всякое бывало - любят его не за это :) софт должен оперировать актуальными данными, а предания старины глубокой - только по запросу. например, зачем мне сейчас весь архив pipe.2032? мне нужны только последних 100 сообщений, где я в дискуссии. и именно по таким принципам должен работать софт в gk11.

> Допустим, что оно верное, остаётся другая проблема: проблематичность отслеживания таймстампов для каждого сообщения, т.е. придётся либо строить кэш, либо завязываться полностью на базах данных, что убирает принцип простоты.

я уже где-то показывал, как работает acceptts. у меня на этом принципе полные бандлы срезов для bosfor делались. но бандлы для 10000-1M сообщений генерировать очень долго, поэтому в gk11 бандлов не будет, принцип старый - сначала списки с msgid, потом сами сообщения. и не нужно хранить acceptts для каждого сообщения, нужно хранить для каждой эхи. в любом случае, это всё заботы клиента.

> дело не в длине, а в том, чтобы софт понимал, что это такое
Видимо, мы про одно и то же говорим =)

> кроме того, если в n сообщений нет ни одного знакомого, можно запросить ещё n, а потом ещё.
А вот это мне уже нравится. Только вот надо придумать, как реализовать подобные смещения.

> например, зачем мне сейчас весь архив pipe.2032? мне нужны только последних 100 сообщений, где я в дискуссии.
Но нодам при синхронизации и парсинге нужно работать с полным списком сообщений, поэтому нужно проработать и переполнение файла эхи.

> принцип старый - сначала списки с msgid, потом сами сообщения. и не нужно хранить acceptts для каждого сообщения, нужно хранить для каждой эхи.
Кажется, начинаю понимать. Можно делать таймстамп последнего обновления эхи и/или преобразовать файл echo/<название> на ноде в формат msgid:ts\nmsgid:ts.
Это куда более реально.

> Но нодам при синхронизации и парсинге нужно работать с полным списком сообщений

не обязательно. я вот смотрю на станцию ii-net и spline, и вижу, что там разное количество сообщений в pipe.2032 :) пути синхронизации неисповедимы, я спокойно на "тыще последних" гоняю

> Можно делать таймстамп последнего обновления эхи и/или преобразовать файл echo/<название> на ноде в формат msgid:ts\nmsgid:ts.

у bosfor был ключ appendts, который вместе с запросом выдаёт и ts синхронизации сервера
ты его сохраняешь, а при следующем синке делаешь запрос /acceptfrom/СОХРАНЁННЫЙTS

но это уже на усмотрение клиента. сервер это добро поддерживать будет (из 1000 способов босфора в gk11 останутся только несколько наиболее простых, а как это будет использовать клиент - это уже его дело). самый простой способ - запрашивать список с n последних (рекомендации по трафику может выдавать и сервер, показывая трафик за последние дни)

в общем, ничего принципиально не изменится, кроме дефолтов клиента, тягающих только последние сообщения (насколько я помню, 51talk умел это через конфиг). но базы сообщений можно будет накапливать, не перескакивая по эхам.

поле acceptts - это такое же поле, как и все остальные, но оно на каждой станции своё. и оно на каждой станции стабильно, поэтому можно ориентироваться на него. но это более сложный путь, для более сложных синхронизаций (оно удобно для бандлов, но тогда бандлы будут только при межнодовом общении, по ключу - это уже тонкости реализации). обычный "последние n сообщений" - это дёшево и просто.

> я вот смотрю на станцию ii-net и spline, и вижу, что там разное количество сообщений в pipe.2032 :)
Это же из-за blacklist.txt =)

> не обязательно.
Но сообщения в эхе могут находиться в разном порядке, поэтому так или иначе проводить полную синхронизацию придётся иногда.

Но я имел в виду другую вещь. Предположим, элементов в эхе 100 000. Когда серверное ПО пытается распарсить список из 100 000 msgid, оформить это в виде массива, выделить для всех элементов память, а потом ещё и манипуляции с такими вещами проводить, то это превращается в очень медленное и трудоёмкое дело.

> у bosfor был ключ appendts, который вместе с запросом выдаёт и ts синхронизации сервера
> ты его сохраняешь, а при следующем синке делаешь запрос /acceptfrom/СОХРАНЁННЫЙTS
В общем, гибрид /x/t/ и /u/e. Вполне неплохо.

> самый простой способ - запрашивать список с n последних
Попробовать, конечно, можно.

> Но я имел в виду другую вещь. Предположим, элементов в эхе 100 000. Когда серверное ПО пытается распарсить список из 100 000 msgid, оформить это в виде массива, выделить для всех элементов память

до 2 млн волноваться не стоит. а когда будет 2 млн - тогда уже будут возможности для любой инфраструктуры :)

> Но сообщения в эхе могут находиться в разном порядке, поэтому так или иначе проводить полную синхронизацию придётся иногда.

потерянное сообщение 10000 назад никого не интересует. а кому нужен полнейший-преполнейший архив - пусть запросит всех. систему блеклиста, кстати, тоже надо делать общей (она так и задумывалась, но не дожила) и обмениваться им, чтобы не было вот таких несоответствий.

> до 2 млн волноваться не стоит.
Я уже на 10 тыс. волнуюсь =) Python и PHP хорошо умеют кушать память и имеют не очень впечатляющую производительность.

> есть ещё нюансик с протоколами ии:// в ii и аналогичными для эх и сообщений...
Упоминание этого дела навело на одну мысль.

Всегда считал использование одной разметки для эх и сообщений немного неудобным для парсинга. Проще было бы чисто с программной точки зрения сделать msg:// для сообщений и echo:// для эх. Ещё достаточно костыльно парсить ====, более удобной альтернативой этой схеме были бы комментарии в стиле Си /* вот так вот */ или Lua --[[ как здесь ]], чтобы просто их заменять на <pre> или </pre>.

// Это просто мысли вслух

>> кроме того, если в n сообщений нет ни одного знакомого, можно запросить ещё n, а потом ещё.
>А вот это мне уже нравится. Только вот надо придумать, как реализовать подобные смещения.

Я думал сделать режим такой: первый забор эхи или рескан n сообщений или полный, поуказанию пользователя. А потом диффы от первого известного клиенту сообщения до последнего в эхе на ноде. Но я плохой изобретатель фидо.

> Я думал сделать режим такой: первый забор эхи или рескан n сообщений или полный, поуказанию пользователя. А потом диффы от первого известного клиенту сообщения до последнего в эхе на ноде.

Неплохо выглядит идея забирать сначала n последних (параметр -n), затем если среди них все новые, то запрашивать -2n:n, потом -3n:n и так далее. Причём хранить на клиенте упоминание о полной синхронизации (если её вообще не было, то сначала фетчим по полной, затем просто ставим метку, чтобы дальше в экономном режиме).

А диффы не очень хороши тем, что на разных нодах бывает разный порядок расположения сообщений в эхе, так что велика вероятность потери даже за небольшой период времени.

200000 - это смешной размер

from random import randint, seed

seed(0)

a = ['000000000000'] + [str(randint(100000000000,999999999999)) for _ in xrange(200000)]
print 'generate 200000 a'

b = [str(randint(100000000000,999999999999)) for _ in xrange(200000)] + ['000000000000']
print 'generate 200000 b'

a = set(a)
b = set(b)

print 'convert to set'

print a & b

ps. а почему код не запоминается надолго? приходится каждый раз его искать, чтобы в строку браузера забить.

замена не подойдёт. во-первых, заменяемый код может уже быть в коде, а во-вторых, внутри кода не должны работать никакие другие парсеры, типа "url в ссылку" и тому подобное.


а так у меня используются msg:// и echo:// потому что лишние двоеточия после // - неудобно читать. я сначала хотел определять эхи не как :эха, а как ::эха, тогда было бы проще разбирать безо всяких ://, но решил лишних двоеточий не плодить

>> Я думал сделать режим такой: первый забор эхи или рескан n сообщений или полный, поуказанию пользователя. А потом диффы от первого известного клиенту сообщения до последнего в эхе на ноде.
>Неплохо выглядит идея забирать сначала n последних (параметр -n), затем если среди них все новые, то запрашивать -2n:n, потом -3n:n и так далее. Причём хранить на клиенте упоминание о полной синхронизации (если её вообще не было, то сначала фетчим по полной, затем просто ставим метку, чтобы дальше в экономном режиме).
Посмотрим что Рома скажет. Технологию то он разрабатывает. Просто когда я думал на базе ii что-то сделать, я думал сделать это так.

>А диффы не очень хороши тем, что на разных нодах бывает разный порядок расположения сообщений в эхе, так что велика вероятность потери даже за небольшой период времени.
Некорректно выразился. Не диффы в прямом смысле, а примерно то, что получаем с ноды сейчас. То есть простое построение разностного списка сообщений, но только с учётом того, что было полученно изначально.

> Посмотрим что Рома скажет. Технологию то он разрабатывает.

технологию ii я уже давно разработал и 4 раза забыл, поэтому это не ко мне вопросы

в моей сети суть такова, что всё это - на усмотрение клиента, а сервер будет просто сервером

ещё один нюанс:

в ii есть запрос /u/e/, который получает список из эх и выдаёт их. в текущем же bosfor, насколько я помню, это не реализовано, и выдаётся просто список сообщений. связано это с тем, что в ii был "список эхи", и "указание на эху в сообщении", в текущей же реализации никакого "списка эхи нет", есть только список сообщений, у которых есть параметр "эха", и по ней всё определяется

поэтому запрос

http://bb.51t.ru/bb/echo/besedka:obsd:humor/lim/50/fmt/msgid

даёт 50 сообщений, которые просто расположены в тех эхах: http://bb.51t.ru/bb/echo/besedka:obsd:humor/lim/50/fmt/flat (если не указывать эхи - то это будет просто 50 последних сообщений станции)

реализовывать режим "как в ii" я не буду, поскольку и полные коллекции эх не очень нужны, и сервер усложнять смысла нет: да, будет режим, выдающий "msgid:echo", вместо "msgid", но это - опционально. то есть, тут клиент сам будет разбираться - или он будет делать по timestamp, или запрашивать n сообщений в каждой эхе отдельно, или брать просто n сообщений со станции. все сообщения в эхе клиент должен забирать только по запросу пользователя (кому нужны rss-новости за 2014 год?), а в остальном - клиент должен быть умнее. а сервер - тупым, как пробка, и быстрым, как пробка.

ps. что-то та станция постоянно отваливается - сейчас написал ответ, а отправить не смог, "сервер не отвечает"

да, при этом логику клиентов придётся менять - либо действительно использовать msgid:echo, чтобы проверять "есть ли сообщение в эхе", либо брать msgid, но проверять не "есть ли в эхе", а "есть ли в базе"

>> Посмотрим что Рома скажет. Технологию то он разрабатывает.
>технологию ii я уже давно разработал и 4 раза забыл, поэтому это не ко мне вопросы
Я не про ii и говорил. Мне достаточно интересно что ты придумаешь и как это будет работать, но без знания твоих идей о структуре данных и общих принципов, я могу опираться только на ii, что некорректно в контексте обсуждения более других технологий.

различия незначительные в серверной части

только клиенты должны стать умнее. поэтому я и думаю, как можно ваши клиенты приспособить, чтобы не форкать - но я же не знаю, как они устроены. у сервера будет несколько возможностей делать, что потребуется - а клиент сам выбирает, как ему удобнее.

>различия незначительные в серверной части
Кстати, ты исходники серверной части откроешь?

>только клиенты должны стать умнее. поэтому я и думаю, как можно ваши клиенты приспособить, чтобы не форкать - но я же не знаю, как они устроены. у сервера будет несколько возможностей делать, что потребуется - а клиент сам выбирает, как ему удобнее.
Ну вот то, что я тут в обсуждении видел, мне понравилось. Так что или прямо в своём клиенте сделаю поддержку или сделаю отдельную версию клиента для работы с этой новой технологией. Правда тут есть некоторая зависимость от первого вопроса в сообщении. Если я не смогу свою ноду поднять, то мне куда скучнее будет делать поддержку.

>> различия незначительные в серверной части
> Кстати, ты исходники серверной части откроешь?

босфор я где-то тарболил. ii12 - доступна. gk11 - это нечто среднее между ними. собственно, единственное, что там осталось - это утвердить стандарты url-ов (ну и, поскольку хочется сделать площадку и для ретро-компьютеров - я сделаю flat-версию, которая нормально работает в netsurf, links grapics, lynx и т.д., за основу возьму сайт OpenBSD, но это уже отдельный проект) и удалить лишние реквесты из босфора

лицензия будет та же - Public Domain

как только соберусь сделать - так сразу и сделаю :) надо только все наработки откопать, собрать в кучу, и выпилить из них Буратину :)

> 200000 - это смешной размер
> [код]

Выполнение этого скрипта заняло у меня 15 секунд. Плюс заметим, что ПО ii для своих нужд требуется и распарсить файлы, и проводить поиск. Нельзя забывать, что на сервер могут приходить (в перспективе) сотни запросов ежесекундно, так что беспокоиться есть за что.

> замена не подойдёт. во-первых, заменяемый код может уже быть в коде, а во-вторых, внутри кода не должны работать никакие другие парсеры, типа "url в ссылку" и тому подобное.
Хорошо, согласен.

> а так у меня используются msg:// и echo://
Вот хотелось бы так же сделать, но для принятия чего-либо нужно всем голосовать (Андрей и Денис в особенности).

> Некорректно выразился. Не диффы в прямом смысле, а примерно то, что получаем с ноды сейчас. То есть простое построение разностного списка сообщений, но только с учётом того, что было полученно изначально.
Теперь я запутался =) Объясни поточнее, пожалуйста, если не затруднит.

> ps. что-то та станция постоянно отваливается - сейчас написал ответ, а отправить не смог, "сервер не отвечает"
Можешь сидеть на резерве http://alicorn.tk/ii , либо у Андрея. Сам замечаю за своей станцией даунтайм.

> в ii есть запрос /u/e/, который получает список из эх и выдаёт их. в текущем же bosfor, насколько я помню, это не реализовано, и выдаётся просто список сообщений. связано это с тем, что в ii был "список эхи", и "указание на эху в сообщении", в текущей же реализации никакого "списка эхи нет", есть только список сообщений, у которых есть параметр "эха", и по ней всё определяется

Поскольку ii исходит из принципа быстродействия и суперпростоты, делать у нас что-то подобное смысла не вижу. Оно будет сильно загружать процессор и ЖД. Даже если это будет не так, то придётся завязываться строго на базе данных (да пусть если sqlite), то это противоречит идее простоты и универсальности.
ii должен ориентироваться на возможность построения по текстовой БД с малыми потерями в производительности.

> поэтому я и думаю, как можно ваши клиенты приспособить, чтобы не форкать - но я же не знаю, как они устроены.
Требуется сделать возможность наличия двоеточия в имени эхи (и идентификацию эхи по нему) и совместимые msgid? В своих клиентах я это обеспечить могу, мне не принципиально.

14.5 секунд - это генерация :) это время уйдёт на загрузку списка :)

ii12 сделана на текстовых файлах

а сервер при этом упрощается, потому что больше нагрузки идёт на клиенты

> Оно будет сильно загружать процессор и ЖД.

жаль, pentium 150 умер. я бы запустил на нём ноду :)

текущая реализация как раз неоптимальна, и точно загружает процессор и ЖД. первая версия ii (которая была сразу после ii на json) была сильно оптимальная, но не была совместима с фетчерами :)

ii пусть остаётся. но лучше и её перевести на формат ii12, чтобы оно было совместимо полностью

> 14.5 секунд - это генерация :) это время уйдёт на загрузку списка :)
Но это же ооочень долго =) и просто недопустимо. 2-3 секунды - максимум для комфортной работы.

> ii пусть остаётся. но лучше и её перевести на формат ii12, чтобы оно было совместимо полностью
Собираюсь определить особенности каждого формата и хорошие мысли, высказанные в этой дискуссии, и наконец-то устроить голосование по стандартам. Но только не сегодня, а то дел, увы, полно =)
Тут же ещё с особенностями софта рассчитать надо, а это помню только я и Андрей.

>> 14.5 секунд - это генерация :) это время уйдёт на загрузку списка :)
> Но это же ооочень долго =) и просто недопустимо. 2-3 секунды - максимум для комфортной работы.

там же специально написано, какая стадия сколько занимает :) основное время - это генерация 400000 записей. у тебя они будут получаться по сети, за сравнимое время :)

а для синка "все со всеми" - и 15 секунд нормальное время. он будет отрабатывать раз в сутки, если будет необходимость. если нет - раз в неделю. всё остальное время - оперирование более короткими списками