Уважаемые Bitcoin разработчики и владельцы майнинг,

Глядя @ работы http://www.tricone-mining.com/limp.html и имеющий опыт работы с материалом высокой производительности, я хотел бы отметить, что в целом многие из этих способов доставки акций весьма неоптимальные. В основном подача getwork / акция не требует таких объектов TCP, как ORDER отправленных пакетов / полученных от шахтера до bitcoind или бассейна. Таким образом, индивидуальный пакет подтверждение будет работать лучше, особенно, когда шахтер за плохое подключение к Интернету, как я.

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

Так что - облегченный протокол getwork.

Одно пакет UDP может содержать несколько сообщений, создание до 1400 байт. 1400 Выбирается, потому что в основном, когда вы получаете доступ с нескольких виртуальных частных сетей, ваш MTU будет срезали 1500. Таким образом, 1400 является безопасным значением компромиссом. Но добыча клиент может исправить это значение одного из его выбора. И даже больше - сервер не должен отвечать с большим количеством сообщений в одном UDP пакетов, чем запрошено клиент! Так что можно было получить 8 работ на getwork запросов, только если клиент просил 8 getworks сразу.

Так что - UDP пакеты в основном конкатенации из нескольких сообщений следующего формата:
структура msg_header {
  неподписанные символ msg_size;
  неподписанные символ msg_opcode;
  символ без знака msg_context_uuid [16];
};

структура msg_work {
  структура msg_header HDR; / * Это в основном C-способ inheritation ... в C ++ это будет msg_work: msg_header * /
  символ без знака работы [80]; / * Последние 32-бит одноразовое значение, но может содержать последовательность битового потока разблокировки (специальную для EldenTyrell) * /
};

Opcodes:
ЗАПРОС РАБОТЫ:
msg_opcode == 1 - Запрос getwork, как правило, ответ 10, 11 или 12
msg_opcode == 10 - структура с msg_work вернулся, шахтер должен обрабатывать эту работу
msg_opcode == 11 - getwork отрицательного подтверждение - слишком много запросов, это опкод может быть отправлен в дружественные узлы
                             в случае слишком много запросов getwork, так шахтер не засада сервера больше;
msg_opcode == 12 - работа признана недействительной (когда новые расчеты блок начал);

ПОЛУЧЕНИЕ ОТВЕТА:
msg_opcode == 20 - ответ тип сообщения msg_work;
msg_opcode == 30 - успешно принята msg_work;
msg_opcode == 31 - доля отвергнута - черствый;
msg_opcode == 32 - доля отвергнуто - недействительно;
msg_opcode == 33 - доля отвергнута - неизвестно;
msg_opcode == 34 - доля отвергнута - продублировать;

ФЕДЕРАЦИЯ СЕРВЕРОВ ВНУТРЕННЯЯ СВЯЗЬ:
msg_opcode == 40 - Я хочу, чтобы обладать правом обрабатывать этот запрос getwork;
msg_opcode == 50 - У меня нет никаких возражений, продолжить с этим getwork;
msg_opcode == 51 - Я уже обработали, что getwork, уронить его;

ТИПИЧНЫЙ MINER <-> BITCOIND ИЛИ БАССЕЙН СВЯЗЬ:
msg_opcode == 1 - отправлено от шахтера до bitcoind занимает около 46 байт запрашивать работу;
msg_opcode == 10 - 126 байт (! только 126 не 2 KB) вернулся из пула Miner msg_work;
msg_opcode == 20 - msg_work найденного нонс вернулся из шахтера в bitcoind;
msg_opcode == 30 - доля хорошо - вернулся из bitcoind к шахтеру;

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

Bitcoind / бассейн НИКОГДА не ретранслирует пакеты на своих собственных.

Для шахтеров за брандмауэром, специальный прокси-сервер может быть запущен, который преобразует сообщения от TCP к UDP протокола. Однако
Такие прокси будут подвергаться DDOS атак из-за самого TCP ... остерегайтесь ...

ТОГДА - как смягчение DDOS может быть реализовано в этом протоколе (не знаю, является ли это хорошо для бассейна или для bitcoind):

Сервер собирает кадр запросов на скажем, 100 миллисекунд. 1 Гбит Интернет, что может быть больше, чем 6'000'000 входящие сообщения для getwork. Затем сервер должен получить только 100 до 1000 лучших getworks по его мнению, из этого буфера и молча уронить остальные запросы. Как тогда сервер может выбрать? Очень просто - по приоритету сортировки - первый сервер будет ранжироваться выше тех, кто послал больше акций в течение последних 60 секунд, а затем сортировать по IP-адресу, где ф, запросившие меньше getworks бы ранжировать выше, чтобы отрезать ботнеты. Затем падение всех остальных 5'999'000 запросов. Но хорошо ... если такой протокол, используемый на всех этапах, он может легко обрабатывать 10'000 getworks в секунду на простом VPS!

Тогда - почему UDP?! Это более сложный?

На самом деле нет ... потому что в UDP он прост в установке репликации связи ... Скажите, вы добавите к вашей горной установки, подключенной к ADSL дополнительно GSM или 3G интернет ... И вы можете передать тот же запрос getwork более 2-х каналов одновременно, и 3-х серверов вашего любимого бассейна .... Это увеличит трафик, но и повысит надежность за счет ВЕЛИЧИНЫ ... Так что в то время как бассейны дерутся 1% больше или на 1% меньше, многие из шахтеров теряют около 2-3% для Интернет простои, некоторые с плохой интернет связи рыхлой около 10-12% (как я).

Для TCP на другой стороне вы бы всегда иметь хлопоты с сохранением состояния соединения и т.д. В то время как в UDP вы должны помнить _комплекта_ шахтер "адреса возврата" в течение примерно 60 секунд, в то время как получать пакеты от него актуальна. А вы бы транслировать ответы на все эти адреса.

Я собираюсь реализовать этот протокол в ближайшее время для собственных целей, но это смешно, когда я, наконец, преобразовать все, что в основе getwork HTTP-JSON.

Поэтому я хотел бы спросить:

1. Кто же поддержит такую ​​инициативу / имеют схожие проблемы?

2. Как код bitcoind должен быть представлен / одобрено? Является ли это дополнение при условии быть добавлены к существующим bitcoind? Как обслуживание отдельного патча-набор может быть довольно скучным ... Также может возникнуть вопросы о том, как это будет реализовано в наилучшем образе (скажем bitcoind в основном полагается на повышении :: ASIO).

С уважением,
В. // BitFury 🙂