Последний пункт написал doesnm

shaos> Последний пункт написал doesnm

Да, не заметил с телефона. :)

У меня статистика считается за сутки сразу после полуночи по тихоокеанскому времени - это 11 утра по Москве или 6 вечера по Владику, поэтому результат любого изменения лучше смотреть на следующий день.

И кстати у меня ведь теперь есть ii://spnet.uplink где можно это обсуждать :)

tuple> А покажи демку, пожалуйста, как с ним работать в каком-нибудь asciinema. Для наглядности, чтобы не лезть в мануалы. :)

Вот поэтому я и не хотел давать ссылку раньше времени. Но без мануалов с любым из моего софта (тем более написанного в первую очередь для себя) вообще делать нечего.

Вкратце — создаёшь stations.txt а-ля такого содержания:

https://sprinternet.io/iii 389
https://hugeping.tk 10000
#https://tgistation.ru 12
http://ii.blcat.ru 4238
http://idec.spline-online.ru 380

Запускаешь фетчер: ./tiifetch.tcl
Запускаешь GUI-клиент: ./tiix.tcl

В выпадающем списке эхи, справа фильтр по сообщениям (0 — читать все), ну а дальше, думаю, разберёшься.

revoltech> ну а дальше, думаю, разберёшься.

А, ну да, ещё auth.txt для постинга нужен. Формат тот же: на каждой строке урла станции и пароль через пробел.

ahamai> без контента сеть мертва.

Ну дык инглиш, мазафака, ду ю спик ит? У меня, например, конента сколько угодно, но на более широкую аудиторию в основном за пределами чебурнетов. Внезапно даже мой гофер какую-то обратную связь даёт: со мной на днях связался какой-то пакистанец, нагугливший по совершенно неожиданному поисковому запросу веб-зеркало моего гоферного блога. И в итоге я от него получил материал (пару дампов), необходимый для успешного завершения одного из моих исследований. Сам в шоке до сих пор. Но я к тому, что через ii/IDEC в его нынешнем состоянии он бы на меня не вышел никогда даже с веб-зеркалами. Он только английский, урду и арабский знает.

ahamai> а о чём мы, три с половиной сисопа ещё можем поговорить, и с кем ещё?

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

ahamai> проблемы привлечения к написанию нового софта (как я называл это в 2014, любительское программирование)

А что, с этим есть какие-то проблемы? Ну, окромя того, что 95% населения даже тикль не хотят осиливать.

ahamai> когда с крупного узла запрашиваешь разом все эхи, он сильно задумывается

Раз Шаос тут свой монстрокод кидал, могу и я свой кинуть (правда, это ещё не окончательный вариант, а в репе этого файла пока вообще нет и ещё долго не будет) чисто по обработке /u/e со стандартным слайсингом:

            e {
              set erange [lrange $pathparts 3 end]
              if {[llength $erange] > 0} {
                set limit 0
                set offset 0
                set lastel [lindex $erange end]
                if {[string match *?:?* $lastel]} { # slice detected
                  set sparts [split $lastel :]
                  set offset [expr {int([lindex $sparts 0])}]
                  set limit [expr {int([lindex $sparts 1])}]
                  set erange [lrange $erange 0 end-1]
                }
                # validate the rest of the echo list
                set erange [lmap ename $erange {expr {
                  [validecho $ename] ? $ename : [continue]
                }}]
                if {[llength $erange] > 0} { # recheck length after validation
                  repdata $sock $ishttp [indexechos $dbfile $erange 1 $offset $limit]
                } else {
                  reperror $sock $ishttp "invalid request"
                }
              } else {
                reperror $sock $ishttp "invalid request"
              }
            }

Но это не самое интересное. Самое интересное — процедурка indexechos:

# echo indexer for /e and /u/e
proc indexechos {dbfile echolist includenames offset limit} {
  set rdata {}
  set oquery {ORDER BY `id`}
  if {$limit > 0} { # trigger limiting logic only with positive limit value
    if {$offset >= 0} { # normal limiting flow
      append oquery " ASC LIMIT $offset,$limit"
    } else {
      set reallimit [expr {-$offset}]
      set realoffset [expr {$reallimit - $limit}]
      if {$realoffset >= 0} {
        append oquery " DESC LIMIT $realoffset,$reallimit"
      } else { # invalid limit, falling back to full query
        append oquery " ASC"
      }
    }
  }
  set query {SELECT CONCAT(`echoname`, ':', GROUP_CONCAT(`msgid`,'|' ORDER BY `id`)) AS `rowcat` FROM (}
  foreach echo $echolist {
    append query "SELECT * FROM (SELECT `id`, `msgid`, `echoname` FROM `msg` WHERE `echoname` = '$echo' $oquery) UNION ALL "
  }
  append query {SELECT NULL,NULL,NULL) GROUP BY `echoname` ORDER BY `echoname` ASC;}
  sqlite3 db $dbfile -readonly true
  db eval $query echorow {
    if {$echorow(rowcat) ne ""} {
      set eparts [split $echorow(rowcat) :]
      set ename [lindex $eparts 0]
      if {$ename ne ""} {
        if {$includenames > 0} {
          append rdata $ename \n
        }
        append rdata [join [split [lindex $eparts 1] "|"] \n] \n
      }
    }
  }
  db close
  return $rdata
}

Вот и с чего бы такой обработчик долго задумывался, если он все эхи (после валидации) в один проход запрашивает?

Сегодня статистика без таверны, которая похоже опять прилегла...

Echoareas
────────────────────────
idec.talks...........518 ██████████████████████████████████████████████████▒▒▒▒▒▒▒▒▒▒
bot.slashdot.........127 ██████████████████████████████████████████████████▒▒
lor.gold..............89 ██████████████████████████████████████████████████▒
lor.opennet...........39 ███████████████████████████████████████
bot.habr.rss..........29 █████████████████████████████
linux.14..............15 ███████████████
spnet.stats............7 ███████
blcat.local............6 ██████
idec.test..............4 ████
std.game...............3 ███
std.rein...............3 ███
im.24..................3 ███
iii.nizya..............2 ██
bot.antropogenezru.rss.2 ██
std.hugeping.micro.....2 ██
english.talks..........1 █
crypto.talks...........1 █
ii.stat................1 █
spnet.uplink...........1 █
────────────────────────
Total                853

Ну тут у тебя SQLite по ходу? Это читерство ;)
Настоящие пацаны БД на текстовых файлах держат ;)

shaos> Ну тут у тебя SQLite по ходу? Это читерство ;)

Да, он самый, как и на клиенте. Меня групконкат спасал ещё на мускуле в бытность вебдевом (период моей жизни, в который я не хочу даже в воспоминаниях возвращаться), выручит и теперь. Очень мощная вещь. И из того же периода я вспомнил трюк с долбаными юнионами, кстати.

shaos> Настоящие пацаны БД на текстовых файлах держат ;)

Да кто против-то, только не жалуйтесь на тормоза при запросе кучи эх со слайсами.

В 19:57 у меня статистика обновляется

И я говорил это не в контексте проблемы, а в контексте работы срезов. Несколько десятков мб трафика в сутки между серверами это вообще не проблема. Да и для меня - стационарного инета у меня нет, на одном номере 26 гб в тарифе на другом 50. В конце месяца обычно на одном телефоне остаётся неиспользованными гигабайт 10, на другом 50 :)

ps. В последнее время думаю, что /u/e нафиг не нужна и только всё усложнила, проще было, действительно, опрашивать эхи по одной. Кроме того это ещё и DoS атака, когда с крупного узла запрашиваешь разом все эхи, он сильно задумывается, а ведь каждую эху можно засунуть в запрос несколько раз... если бы не старые клиенты, я бы отрезал её вообще, оставив только e. Но уже ничего не сделаешь, так исторически сложилось.

> Да, он самый, как и на клиенте

Кстати SQLite расслабляет - лучше сразу на MySQL/MariaDB ориентироваться. Например в SQLite ключом можно чо угодно сделать (насколько я помню) и порядок записей всегда хронологический, а в MySQL если ты не сделал ORDER BY оно выльется как попало в зависимости от того как оно там внутри само заполнило дырки...

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

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

> Вот и с чего бы такой обработчик долго задумывался, если он все эхи (после валидации) в один проход запрашивает?

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

> Ну дык инглиш, мазафака, ду ю спик ит? У меня, например, конента сколько угодно, но на более широкую аудиторию в основном за пределами чебурнетов.

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

и мне неинтересно болтать по английски. мне интересно по-фидошному :)

раньше хоть малое сообщество было, сейчас вообще сверхмалое

> А что, с этим есть какие-то проблемы? Ну, окромя того, что 95% населения даже тикль не хотят осиливать.

да, разумеется. клиентов сейчас нет. раньше все что-то делали, у меня был txt и http клиент, кто то делал клиент на dialog, был клиент на py-tk, на qt5, на android. MRD на java me пытался клиент набросать :) А сейчас только вечно живой цезий ну и твой клиент появился. Всё.

да, я буду писать про 0.7 новости на лоре и опеннете, делать что-то ещё.

но как, если тут и общения практически нет (надо хоть свою эхублог развивать активнее, ещё анекдотов хотя бы принести), и клиентов полторы калеки: нет инфраструктуры для заинтересовывания пользователей

ahamai> и мне неинтересно болтать по английски.

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

ahamai> мне интересно по-фидошному :)

Что даёт фидошность? Широкие массы вот это понимают: есть проблема — есть исходящая из неё задача — есть решение. Здесь же какая задача для решения какой проблемы решается? Вот и донеси это до людей, если знаешь ответ на этот вопрос.

Для меня, например, ii/IDEC решает задачу цензуроустойчивости и распределённости при сохранении доступного и легковесного протокола. Поэтому я бы хотел его видеть вместо всяких форумов, мейлинглистов и прочих гуглогрупп как минимум. Везде. На всех языках. Хотя бы в нынешнем виде.

ahamai> раньше хоть малое сообщество было, сейчас вообще сверхмалое

Ну с таким подходом неудивительно.

ahamai> да, разумеется. клиентов сейчас нет.

Так это следствие мною указанного неосиляторства.

ahamai> нет инфраструктуры для заинтересовывания пользователей

Поэтому вы обсуждаете, как обустроить вебморды, вместо того, чтобы заняться более няшными core-клиентами, укрепляющими распределённость сети. Яснопонятно.

Это сообщение ii://fiTy34vIAoqowA6GTpxX
пришло после этого ii://d9fGfA6s7AVhMIQb0we9

Хотя хронологически они написаны в обратном порядке.
Я сфетчил их с ноды shaos. Там они тоже в обратном порядке. Хорошо бы разобраться, как такое происходит.
P.S. Edited: 2024-11-03 21:28:42

А почему они выводятся в обратном порядке? Я помню, давно, в клиенте для андроида часто такое было, и там потом дорабатывали клиент, что бы они выводились в порядке "времени написания".
P.S. Edited: 2024-11-03 21:38:06

btimofeev> А почему они выводятся в обратном порядке? Я помню, давно, в клиенте для андроида часто такое было, и там специально делали, что бы они выводились в порядке "времени написания".

Ну, я так понимаю выводятся в порядке в каком приняла её станция. Иначе возникают приколы, типа через 12 часов пришло сообщение и оно сразу затерялось -- его никто не увидит. Моя станция показывает так, как приняла. Станция shaos видимо тоже.

Дело не в том, что порядок другой. А в трм что сообщения информационно зависимы друг от друга. То есть на станцию shaos попал ответ на сообщение, которого не было на shaos. И видимо, не было на станции ahamai. А потом пришел сам ответ. Как это возможно?

hugeping> Как это возможно?

Вероятно, кто то отдает по фетчу не в том порядке..

жди моего ответа, когда хаос его польнет :)

ps. поэтому я и не люблю, когда все всех фетчат. по мне пойнты фетчат только свои станции, а у фетчинга узлов есть топология

hugeping>> Как это возможно?
hugeping> Вероятно, кто то отдает по фетчу не в том порядке..

Поясню ещё раз по другому.

Есть сообщение от ahamai ii://fiTy34vIAoqowA6GTpxX (написано на станции blcat) 20:43:39
Есть сообщение-ответ ii://d9fGfA6s7AVhMIQb0we9 от revoltech (написано на станции spnet) 20:51:24

Очевидно, что чтобы ответить на сообщение, сообщение ahamai сначала должно было быть получено станцией spnet. (Иначе, reply будет указывать на несуществующее сообщение.)

После этого, revoltech фетчит его и пишет ответ. Отправляет его на станцию spnet. И этот ответ НЕ МОЖЕТ встать РАНЬШЕ сообщения от ahamai. Но в индексе shaos он стоит РАНЬШЕ. Где-то есть проблема.

Надо разбираться.

Повторяю, меня не смущает сам факт нарушения порядка, но конкретно эта ситуация выглядит как невозможная. Кто то может меня разубедить?

я уже полдня назад ответ написал, только шаос медленный :)

http://ii.blcat.ru/rCu2q7hJ6T7vqKWjikjW

когда rt пишет свой ответ на shaos, моего сообщения там нет, физически

У меня появилась ГИПОТЕЗА.

1) revoltech фетчит себе куда-то локально эхи из разных мест
2) revoltech сфетчил сообщение ahamai с ноды blcat
3) revoltech формирует в своём клиенте ответ на сообщение и отправляет его spnet. reply указывает на сообщение с blcat
4) spnet НЕ ПРОВЕРЯЕТ reply вообще и берет это сообщение (считаю, должен был отбросить)
5) ЗАТЕМ spnet забирает сообщение на которое был ответ с blcat

Это всё объясняет. revoltech? shaos? я прав?

iiii> я уже полдня назад ответ написал, только шаос медленный :)
iiii> http://ii.blcat.ru/rCu2q7hJ6T7vqKWjikjW
iiii> когда rt пишет свой ответ на shaos, моего сообщения там нет, физически

Ага, я эту гипотезу и выдвинул тоже (см ii://5R0bd1lXAfHAJH9bFWvs )
Но spnet не должен был принимать сообщение с битым reply! В этом проблема. Это надо фиксить.

> 4) spnet НЕ ПРОВЕРЯЕТ reply вообще и берет это сообщение (считаю, должен был отбросить)

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

почему оно битое-то? это абсолютно штатная ситуация и так было всегда

iiii> почему оно битое-то? это абсолютно штатная ситуация и так было всегда

Поинт шлет ноде сообщение с reply на несуществующее сообщение и это ок? Я не согласен. Я рублю и буду дальше это делать. Ну, главное что причина понятна.

> Поинт шлет ноде сообщение с reply на несуществующее сообщение и это ок?

Естественно. Что значит несуществующее, у тебя на ноде его нет не значит, что оно не существующее. В этапе фетчинга может сбойнуть фетчер или сервер, и у тебя сразу 40 сообщений могут вылететь из базы, и прийти только следующим фетчингом.

>> Поинт шлет ноде сообщение с reply на несуществующее сообщение и это ок?

iiii> Естественно. Что значит несуществующее, у тебя на ноде его нет не значит, что оно не существующее.

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

> Если поинт одновременно питается у нескольких нод - это ненормальная ситуация.

тут я согласен :) но в рамках распределённой сети ситуация вообще штатная

по мне так тут shaos-у надо почаще фетчить других :)

iiii> тут я согласен :) но в рамках распределённой сети ситуация вообще штатная

Я устал объяснять, почему эта ситуация не штатная. Конкретно эта, а не вообще некоторые абстрактные перемешивания. Выше все детально описано. Кому надо, разберутся.

iiii> по мне так тут shaos-у надо почаще фетчить других :)

Это не спасло бы от конкретно этой ситуации.

iiii>> по мне так тут shaos-у надо почаще фетчить других :)

hugeping> Это не спасло бы от конкретно этой ситуации.

Ладно, я реально устал. Пока перестаю читать idec.talks, а то напрягаюсь слишком.

> Я устал объяснять, почему эта ситуация не штатная.

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

и ровно то же самое было в фидо. в том числе пропадание целых сегментов с концами :) у нас то можно хоть что-то выфетчить, а в фидо аутбаунд.

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

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

> Это не спасло бы от конкретно этой ситуации.

это спасло бы от медленно ходящих сообщений по сети :) как будто реально голубями из США :)

> Если у меня его нет, то у поинта его тоже нет и ответить он на него не может

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

вообще, у кого база неполная, repto вообще может ссылаться на сообщение, которое было написано 5 лет назад, у одного нода оно есть, у другого нет. консистентность эх же не гарантируется.

или у одного удалено, а у другого нет.

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

в аликорновских архивах почему-то для некоторых тем нет исходных сообщений.

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

я вот даже не вспомню, в фидо вообще хоть какой-то аналог repto был?

repto я прикрутил уже вообще в последний момент, поэтому он таким кривым видом прописывается, сначала его вообще не было как такового

Ну я ж вчера ещё объяснил сей феномен - всё так, но при приёме сообщений никто не отбрасывает сообщения по несуществующему repto, т.к. оно может прийти позже (и приходит в некоторых случаях) или вообще может быть уже удалено - так всё норм. А фетчить всех со всех это надёжно. Вот сделаю себе адаптивный фетч и буду опрашивать всех чаще, чем раз в полчаса (кстати если бы с ноды blcat фетчил не только я, а и другие ноды, то сообщение на которой отвечал revoltech могло бы всплыть в сети и пораньше).

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

Да ну конечно - фидо в штатах же родилось и до сих пор как-то шевелится, хоть и по IP.
И левонеты кстати некоторые до сих пор существуют - я вопрос немного поизучал пару-тройку лет назад...

Я говорю про популярность. Будучи уже нодой, я был подписан на разные мировые эхи и знаю, какой там был трафик. idec.test по сравнению с этим это твиттер.

Всё равно все фетчат все ведёт к перемешке, хотя, конечно, если пойнт отвечает на той же станции, что и забирает, то кроме случаев сбоев и удалений там по определению есть сообщение, на которую отвечает.

Для подобных вещей в elp и bosfor был тэг topicid
http://blcat.ru:15555/m/53NZLKKTR2OS6NVZZP5W

.. который содержал исходный msgid и наследовался при каждом ответе. То есть, даже при выпадении сегмента, включая исходное сообщение, цепочку можно было восстановить. Я ОЧЕНЬ жалею, что не догадался вставить topicid в изначальный ii. Вообще, я очень долго думал и решал, и решил окончательно - в 0.7 я буду вставлять topicid в сообщения. Хоть это и будет касаться только сообщений, созданных на моей станции, ну хоть в чём-то археологи будущего будут мне благодарны. :)

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

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

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

В каком году это было? Всемирный пик фидо был в 1996 году, а потом пошёл спад

Я был немножко фидошником ещё когда жил в Екатеринбурге в 1997-1998 (всё как надо с модемом и т.д.)

Потом немножко левонетчиком (ZXNet в начале нулевых) - мне не понравилось т.к. там был трешак...

Это я в том смысле, что по ex-USSR оно с запозданием прошлось, когда во всём остальном мире уже был спад...