Topic: Telegram minig pool (Read 772 times)

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

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

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

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

на биржах, обычно пользуются этим сервисом https://www.cloudflare.com/ +скрывает реальный айпишник сервера, но даже этот сервис, чутка увеличивает время отклика.

воркер подключается к телеграм через телеграм-прокси(по типу стратум-прокси)

будет защищена от дидос атак

Вы хотите входные данные статистики и все аккаунты регить через бота? То есть вы создадите учетку в тг, которая будет админом бота и туда отдавать инфу? Там есть ограничение на кол-во запросов с одного юзера, то есть вам не даст, например, зарегить 10 юзеров в сразу в секунду. То есть та же защита от ддоса может обернуться банальными тормозами сервиса. Если я правильно понимаю о чем вы.

Компонент высокого уровня (язык запросов API / API)
С точки зрения компонента высокого уровня клиент и сервер обмениваются сообщениями внутри сеанса . Сеанс подключен к клиентскому устройству (точнее, к приложению), а не к определенному соединению http / https / tcp. Кроме того, каждый сеанс присоединен к идентификатору пользователя, с помощью которого фактически выполняется авторизация.

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

Существует несколько типов сообщений:

RPC-вызовы (клиент-сервер): вызовы API-методам
RPC-ответы (от сервера к клиенту): результаты вызовов RPC
Полученное подтверждение приема сообщения (или, скорее, уведомление о статусе набора сообщений)
Запрос состояния сообщения
Многостраничное сообщение или контейнер (контейнер, который содержит несколько сообщений, необходимо отправить несколько вызовов RPC одновременно через HTTP-соединение, например, контейнер может поддерживать gzip).