tiphareth: распределенный блогосервер

bigturtle
2007-12-05 18:06 (ссылка)

Ситуация:
Пользователь пришел на фронтенд-сервер A.
Его блог живет на бэкэнд-сервере B, который временно лежит.
Сервер C имеет кэш блога этого пользователя.

Вопрос: как серверу A узнать куда идти за данными?

(Ответить) (Ветвь дискуссии)

tiphareth
2007-12-05 18:25 (ссылка)

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

Адекватный механизм для этого реализован
в NNTP. У бакэнда A есть некоторое количество
апстрим-серверов, которые передают ему контент.
Если B не зарегистрирован на A, тогда все:
они не знакомы, а B лежит. Если зарегистрирован,
тогда вместе с B задана и подсетка промежуточных
узлов, которым разрешено ретранслировать контент.
Бакэнд A опрашивает эти промежуточные узлы
на предмет контента. Всего таких промежуточных
узлов, предположительно, не больше, чем
несколько сотен, иначе таблицу роутинга
придется делать динамическую, а это
затрудняет авторизацию. Вот с этих
узлов и следует добывать контент.

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

Такие дела
Миша

(Ответить) (Уровень выше) (Ветвь дискуссии)

bigturtle
2007-12-06 14:42 (ссылка)

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

(Ответить) (Уровень выше) (Ветвь дискуссии)

tiphareth
2007-12-06 22:46 (ссылка)

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

>И еще вопрос с анонимами - любой сервер должен позволять читать >открытый контент.

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

Такие дела
Миша

(Ответить) (Уровень выше) (Ветвь дискуссии)

	bigturtle 2007-12-07 16:07 (ссылка)
	Негибко как-то... (Ответить) (Уровень выше)

pzz
2007-12-05 20:42 (ссылка)

Прочел ТЗ, ничего не понял. Хотя вроде и не дурак :-)

Подумай о том, что с учетом того, сколько сейчас стоит место на диске, и того, что быстрый интернет стал доступен практически всем, можно сделать полностью распределенный p2p блог.

У каждого на машине хранится его собственный блог, и те блоги, которые он читает постоянно. По мере возможности, машины синхронизируются между собой. Если меня занесло почитать блог, копии которого у меня нет локально, он синхронизируется on demand.

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

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

(Ответить) (Ветвь дискуссии)

tiphareth
2007-12-05 21:18 (ссылка)

Может, ты и прав, но почему-то этого никто не реализовал.

>У каждого на машине хранится его собственный блог, и те блоги, которые он >читает постоянно. По мере возможности, машины синхронизируются между собой.

Даже раз ж 10 минут поллить обновления
400 дневников на том же компьютере жрет 3/4 ресурсов
средней машины (экспериментальный факт).
Если они удаленные, и на разных компах - это
вообще трындец. Думаю, поэтому так и не делают.
Кстати, пуш-протоколы в сети не зря все вымерли.
Такая штука просто не может работать.

Хотя, кто знает

Такие дела
Миша

(Ответить) (Уровень выше) (Ветвь дискуссии)

pzz
2007-12-05 21:47 (ссылка)

Это смотря, как поллить. Если это делать, как ЖЖ это делает (кстати, понятия не имею, как), то готов поверить, что оно сколько угодно ЦПУ сожрет. А если по уму делать, то 400 дневников раз в 10 минут - это вообще незаметная нагрузка. Как и раз в 10 секунд.

Hint 1: чтобы узнать, что 2 синхронизируемых объекта находятся в одинаковом состоянии, достаточно подсчитать cryptohash от их контента, и сравнить. Cryptohash можно считать инкрементально, по мере добавления новых записей. Чтобы узнать, где именно они расходятся методом деления пополам, нужно ln N операций, где N - число записей, на которые можно разбить дневник. Реально такой алгоритм сходится очень быстро.

Hint 2: нечто подобное делает rsync.

(Ответить) (Уровень выше) (Ветвь дискуссии)

tiphareth
2007-12-05 22:13 (ссылка)

Это разумно. Но предполагает добрую волю и минимальную
грамотность индивидуального блоггера. Между нами - весьма глупое
предположение.

Не, 40-50 блогосерверов вроде LJR, с 10-30 тысячами
пользователей каждый, и культурным социальным контрактом
который реально энфорсится (вроде нашего) - это оптимум
для блогосферы в полмиллиона-миллион.

(Ответить) (Уровень выше)

	aspirantus 2007-12-05 21:53 (ссылка)
	А как это всё поисковики индексировать будут? (Ответить) (Уровень выше) (Ветвь дискуссии)

	pzz 2007-12-05 22:04 (ссылка)
	Это хороший вопрос. Очевидный ответ на него заключается в том, что они будут сканировать web-овскую суперноду. Неочевидного ответа я не знаю. (Ответить) (Уровень выше)

(Анонимно)
2007-12-06 00:03 (ссылка)

реально хорошо бы распределенную читалку: которая логинится на все сервера (ЛЖ, РЛЖ, ГЛЖ, ...) и сохранят прочитанное локально (типа, в наш век гигабайтов много текста не бывает). поддерживает переименование
блоггеров (с переездом на другой журнал) во многом это освободит
юзверя от зависимости...

(Ответить)

	yushi 2007-12-06 22:22 (ссылка)
	Гнездо у них вот, насколько я понимаю. (Ответить) (Ветвь дискуссии)

tiphareth
2007-12-06 22:43 (ссылка)

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

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

Такие дела
Миша

(Ответить) (Уровень выше)