subj

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

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

1. даты сообщений

я считаю их необходимо отдавать в спискес идентификаторами. вы правы в том, что никому неинтересны архивы эхи за последние 2 года, но миграция - это не выход (об этом ниже). мне надо получить список сообщений с датами, положить их в склайт, сделать select id from msgs where date > вчера, перенаправить вывод в курл, выводом курла заполнить недостающие куски. потом я их попуржу из базы запросом delete from msgs where date > прошлый месяц.

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

2. склайт

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

вообще можно описать только протокол обмена сообщениями. формат хранения на диске - это специфика реализации.

3. индексы эх и миграция

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

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

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

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

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

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

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

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

5. личный совет

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

какие-нибудь идеи?

>не вижу проблемы - это a. нода должна принимать входящих юзеров, как я понимаю - это b.

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

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

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

можете объяснить на пальцах в чём конкретно проблема? хеш, автор, дата, сабж, тело - это всё части сообщения, что мешает кроме хеша выдать ещё и дату? возможно я человек новый, но проблемы я не вижу. select id, date from msgs where date >= requested_date и выдать это в вывод.

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

>А вообще - вы фетчер, вам и карты в руки. Хоть метод биссектрисы применяйте :) Вы же сами выбираете, что фетчить, никто вам не указ.

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

>это обсуждали буквально вчера. и какой там формат, и какой способ БД может быть. к сожалению, обсуждали мимоходом и в im.1406, а не в dev. надо будет, наверное, это обсуждение перенести.

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

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

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

из-за того, что вы в это упёрлись возникают другие проблемы: надо мигрировать, выдаются все сообщения с начала времён, хоть их никто и не просил. а всё что надо чтобы этого избежать - ёбаная дата в utc+0. вместе со списком сообщений, либо уметь на входе распознать откуда запрашивают. например /m/ii.dev.14/1401767669, а реализация уже сама по базе сверится. /m/ii.dev.14/0 - сообщения с начала времён.

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

>эту работу могут делать компьютеры

ну сделайте

>да. я сегодня ещё буду объяснять, почему сложилоь так, а не иначе. только найду человека, который бы меня об этом спрашивал. :) в общем случае http://51t.ru/list.txt

ну объясните уже наконец один раз, напишите на какой-нибудь страничке в интернете. я новый человек в сети, откуда я его должен взять? скачать все сообщения в сети, потом grep | sort | uniq? а не скачивая все сообщения никак? ну пиздец.

в склайт это select id from echos и отдать поинту то, что есть у меня, такой же запрос можно сделать ко всем аплинкам, а они к своим аплинкам. получится p2p сеть в которой серией запросов можно собрать весть список эх и иногда обновлять. новые эхи будут постепенно расползаться по нодам.

>поэтому и предложен был вариант либо "поток zlib + поток заголовков" либо "поток zlib в sqlite, с нужными заголовками"

это не так важно, попробую объяснить. если курл читает чанками и сразу ложит в файл, то не важно злиб там или не злиб. но чтобы только запустить интерпретатор питона понадобится 3-5 секунд, а он ещё что-то делать должен. скорее всего он выест 100% 400-х мегагерцового мипса который стоит на этом роутере, залезет в своп да юсб-диске со своим сраным сборщиком мусора. тащить надо всю сеть by design. это значит, что если трафик в сети будет значительным, то роутер будет работать 24/7 постоянно копируя всю сеть. значит скорее всего он ничего другого делать не будет.

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

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

вы вообще понимаете сложность сети? я имею ввиду вычислительную сложность. вы понимаете, что в таком случае сложность будет расти квадратично количеству участников, да? все отправляют сообщения всем, каждый должен получить копию каждого сообщения. для десяти участников это 100 попугаев, для 30 участников это 900 попугаев.

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

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

>zlib - для сжатия. для минимального места на диске.

zip не творит чудеса. место на диске всё равно ограничено.

>откровенно говоря, если вам не нужны пойнты, то всё, что вам нужно, работает вот так, хоть на busybox:

если мне не нужны поинты, значит я поинт

>скажите, вы фидо вообще видели? если да, то к чему эти вопросы - все основные принципы такие же.

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

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

желаю удачи.

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

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

>если вы тянете эху, она должна быть у вас целиком.

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

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

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

вы всё таки не торопитесь, подумайте. не будете менять ii, да и хуй с ним, сделаете iii.