0. URL-адреса
----------------------------------------------------------------------------------
URL: http://yyz.us/bitcoin/pushpool-0.4.tar.gz
Repo: https://github.com/jgarzik/pushpool


1. Проблема
----------------------------------------------------------------------------------
С недавним slashdotting и результирующей приток новых пользователей, сетевой протокол «getwork» используется в горнодобывающей промышленности показывает некоторое напряжение, особенно в бассейнах. Шахтеры запросить работу один раз каждые 5-10 секунд, используя HTTP JSON-RPC, который имеет несколько вопиющих недостатков, которые приводят к ненужной нагрузке на сервере:

• HTTP / 1.1 постоянные соединения являются редкостью, возможно, потому, что bitcoind их не поддерживает. Это приводит к новому соединению TCP от каждого шахтера, каждые 5-10 секунд, в одной и той же сети хоста.
• «Getwork» данных составляет всего 256 байт, но HTTP заголовки и бинарные к шестнадцатеричном кодирования для JSON увеличить полезную нагрузку более чем в два раза
• Реализация официального Биткойн клиента сервера RPC является по существу однопоточный контур, в котором запросы от клиентов B, C и D будут остановленных и игнорировали до запроса клиента А является закончена - или 30 секунд (см -rpctimeout). Этот алгоритм не допускает высокую частоту запросов TCP из нескольких потоков / компьютеров.

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


2. Цели разработки для решения
----------------------------------------------------------------------------------
Я написал сервер демонстрационного бассейна (ака а «getwork» прокси-сервер), который функционирует таким же образом, к недавно обсуждалось poold.py: Большое число шахтеров подключения к серверу пула, который прокси запросы «getwork» JSON-RPC на официальный клиент Bitcoin. Эта демонстрация сервер реализует новый двоичный протокол, который был разработан для удовлетворения следующих целей:

• Постоянные соединения TCP, чтобы устранить TCP отключить + восстановить поведение шахтеров
• Сеть эффективная для общего случая использования: один сетевой пакет для «getwork», один сетевого пакета для возвращаемых данных.
• Сеть эффективная для подобных случаев применения (monitorblocks, monitortx), где клиенты подключаются, а затем пассивно ждать событий в реальное время для доставки
• Существующий шахтер клиент рабочих процессов поддерживается, для минимизации сетевого воздействия изменения протокола на шахтерах
• Поддержка "толчок горнодобывающей промышленности," где сервер доставляет новую работу шахтеров Незапрошенных (то есть. без шахтера первой передачи сообщения «getwork»)

Эта не является предназначен для замены JSON-RPC API, но дополнить его для конкретных случаев применения. Да, это означает, что bitcoind будет слушать три сетевые порты: P2P сеть, JSON-RPC, и бинарная RPC (хотя, как сейчас, только P2P требуется для работы; сервера всегда по желанию).


3. Давайте начнем с примера протокола: сегодня добыча getwork
----------------------------------------------------------------------------------
Конкретные детали самого протокола в ubbp.h и protocol.h указанного выше URL (pushpool-0.1.1.tar.gz). Ниже приведен пример, чтобы обеспечить соответствующее введение:

* Соединение TCP разбивается на сообщения. Каждое сообщение имеет 64-битный заголовок, с 8-битным опкодом и 24-битовой полой длиной.
* Шахтерская клиент подключается к TCP серверу, и выдает сообщение LOGIN, который сжимает данные JSON входа + SHA256 хэша (данные + Shared Secret).
* Сервер отвечает с OP_LOGIN_RESP сообщи, сжатым форматом JSON, с указанием опций и возможностей
* Клиент выдает OP_GETWORK MSG (8 байт)
* Сервер отвечает с OP_WORK сообщ (264 байт)
* Клиент использует CPU / GPU для работы над доказательством правильности работы решения ...
* Клиент выдает OP_GETWORK MSG (8 байт)
* Сервер отвечает с OP_WORK сообщ (264 байт)
* ...

Приведенный выше пример намеренно соответствует существующему клиентскому рабочему процессу шахтера JSON-RPC «getwork» сегодня. Miner клиенты могут даже поддерживать лицо без операции по конвейерная в OP_LOGIN и OP_GETWORK запросы вместе, и закрывая соединение TCP. Stateless операция не рекомендуется, но является поддерживается для того, чтобы поддерживать самый широкий спектр существующих горнорудных клиентов.


4. Завтра добыча: толчок добыча
----------------------------------------------------------------------------------
Когда блок или ТХ прибывает, то предпочтительно, чтобы сразу приступить к работе на новой работе. С точки зрения сервера, это классическая проблема данных вещания, где сервер хочет вещать N различных частей работы N шахтеров. Следовательно, "толчок добыча" где сервер толкает новую работу проактивно в шахтерских клиентов.

Этот новый сетевой протокол поддерживает толкая добычу, как показано в следующем примере:

* Клиент подключается к серверу, выдает сообщение LOGIN с "send_me_work" установленный флаг
* Сервер отвечает OP_LOGIN_RESP сообщ
* Сервер отправляет OP_WORK Сообщи
* Сервер отправляет OP_WORK Сообщи
* Сервер отправляет OP_WORK Сообщи
* ...


5. Подобный вариант использования: monitorblocks
----------------------------------------------------------------------------------
Гэвин Андресен есть патч в его GitHub, который обеспечивает очень полезную функцию: когда новый блок получили (monitorblocks) или новую транзакцию бумажника (monitortx), bitcoind посылает HTTP POST на указанный URL. Таким образом, monitorblocks обеспечивает мониторинг в режиме реального времени в сети Bitcoin и monitortx обеспечивает мониторинг в режиме реального времени локального кошелька. Такой род featureset проталкивает данные, как происходят события, а не заставлять оператор сайта опрашивать JSON-RPC для определенных операций для завершения.

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

* Клиент подключается к серверу, выдает сообщение LOGIN с "send_me_blocks" установленный флаг
* Сервер отвечает OP_LOGIN_RESP сообщ
* Сервер отправляет OP_BLOCK Сообщи
* Сервер отправляет OP_BLOCK Сообщи
* Сервер отправляет OP_BLOCK Сообщи
...

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


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

• написать сервер / прокси-сервер в пул, который поддерживает новый протокол (сделано)
• взломать существующие Проходчик клиентов (cpuminer, oclminer, кажется легкой мишенью) для поддержки нового протокола. волонтеры?
• итерация, тест, комментарий. итерация, тест, комментарий. мыльная пена, полоскание, повторите
• Когда люди счастливы, реализовать в официальном bitcoind
• параллельно с любым из вышеуказанных усилий, обновления rpc.cpp официального bitcoind с разумной реализацией HTTPd

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



Приложение 1: Часто задаваемые вопросы
----------------------------------------------------------------------------------
Q. Зачем придумывать новый протокол? Почему бы не использовать буферы протокола Google или XDR?

А. Protobuf и XDR и требуют базового формата пакетирования, например, UBBP, что я подарил здесь. Это означает, что выбор будет UBBP + Protobuf или UBBP + JSON. Учитывая объятия Bitcoin сообщества о формате JSON, был выбран последний. JSON, на самом деле более гибким, чем protobufs, потому что больше динамические структуры данных могут быть описаны с использованием JSON.


Вопрос: Почему вы не вопиющие проблем в getwork?

A. Я сосредоточился исключительно на сетевом эффективный протокол. Выбор реализации getwork выходит за рамки данной работы.


Вопрос: Что такое состояние / качество этой версии кода?

А. Э-э, он компилирует и работает ... но ни один клиент еще не существует для него. Без клиента рудничной для тестирования, это о том, как полезно, как плевки на рыбу ...