Стартовая страница

# Andrew Lobanov to revoltech @ Re: Стандарт @ idec.talks 27/10/24 11:22

AL>> Ты бы хоть иногда из крупных городов куда-то выезжал. Слайсы позволяют мне использовать IDEC в деревне, где интернет настолько нестабилен, что без слайсов можно просто забить на эти ваши эхи и общение в них.
revoltech> Внезапно, я сам в селе. Интернет спутниковый.

Это что-то на богатом.

AL>> Просто сделай новый транспорт. Там уже можно считать хоть точку в конце, хоть любую другую метку как частью протокола транспортного уровня, а не ii/idec.
revoltech> Сделаю. Клиент tii (а конкретнее — компонент tiifetch), собственно, уже поддерживает выкачивание по гоферу, нексу, спартану и джемини. Не на чем только это всё потестить покамест.

Твой клиент не работает с твоей нодой?

AL>> Почему?
revoltech> А кто её передаст, точку эту?

Твоя нода на новом транспорте?

AL>> Для этого вообще никакой протокол не нужен. Просто паковать всю станцию в бандл и сразу отдавать клиенту. Ну и что что там несколько сотен мегабайт? Зато всё и клиент сам разберётся что ему надо, а что нет.
revoltech> Вот для первого выкачивания такая опция не помешала бы. Иначе ему придётся качать те же несколько сотен мегабайт, но маленькими фрагментами.

Что повышает надёжность передачи на нестабильном канале.

AL>> Мы и определились и отказались от максимализма.
revoltech> Вместе с минимализмом.

Всё так. От крайностей одни неприятности.

+++ Caesium/0.4 RC1





# revoltech to Andrew Lobanov @ Re: Стандарт @ idec.talks 27/10/24 12:02

AL> Твой клиент не работает с твоей нодой?

Моей ноды ещё не существует.

AL> Что повышает надёжность передачи на нестабильном канале.

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

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

1) скачивания списка айдишников в эхе (GET /u/e),
2) скачивания бандла (GET /u/m).

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

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

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