hbs2/docs/todo/websockets.txt

52 lines
2.9 KiB
Plaintext
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

TODO: websockets-transport
Предлагается следующее решение:
- Пир стартует и пингует/получает PEX по UDP - это, вроде бы, работает.
- Пир получает расширенную информацию о пирах --- например, путем запроса
ссылки или еще как-то (TBD), что бы не делать лишний протокол.
- В отдельном потоке пир поднимает сервер
- Сервер ведёт список список клиентов, ключом является публичный ключ
(либо же нонс - лучше нонс)
- Сервер ждёт соединений и трекает их в общем каком-то стейте
- Возможно, поднимает "пира" и использует те же самые команды,
правда в нашем случае только GetBlockChunks, используя в качестве
транспорта реаилзацию WS
- Через какое-то время после старта сервера, пир пытается поднимать
треды с ws - клиентами. Один клиент -- один пир. Проверяет, если
соединение уже установлено с сервером - то запрашивает трубу для того
соединения. "Труба" -- это реализация пира через какой-нибудь TChan
для уже имеющегося соединения.
- Если соединения нет, то пытается поднять соединение со стороны
клиента
Логика работы через WS существенно другая, полагаем, что пиры
изначально связываются по UDP/Ping/PEX.
Однако, в дальнейшем можно и бутстрап и всё прочее делать,
указывая префикс протокола ( ws://xxxx или udp:/xxxx ) в
URI пиров.
На каждого пира запускается свой поток скачивания, аналогично
UDP. Потоки отгнивают, если теряется авторизация (?), все
такое же.
Таким образом, WS пир это или тред вокруг websocket-клиента,
либо же тред вокруг трубы, торчащей из вебсокет-сервера.
Является ли проблемой, если получится одновременно установить
и клиентское, и серверное соединение?
Надо бы понять. Возможно, ничего специально делать не надо,
будет две трубы - да и пусть себе.
TBD: udp-relay
TBD: ws-relay