Вот диаграмма последовательности, которую я сделал для сообщений, которыми обмениваются как часть загрузки наборов транзакций-кандидатов, на которые ссылаются предложения:
To send a message, a component needs a PeerImp object (generally held via shared_ptr) on which it calls the send(shared_ptr) method. There is only one generic implementation of send, and it handles every тип сообщения буфера протокола . Этот вызов возвращает void (т.е. без объекта запроса).
Когда сообщение получено от однорангового узла, вызывается метод onMessage(MessageType) для этого типа сообщения. Для каждого типа сообщения существует своя перегрузка onMessage.
Учитывайте при написании кода для HTTP. Популярная идиома в JavaScript выглядит так:
const response = await http.get(url, params)
Есть некоторые важные различия между этим шаблоном и шаблоном для RTXP (официальное название нашего протокола сообщений):
HTTP имеет связь между запросом и ответом. RTXP обычно не имеет такой связи, но в одном примечательном примере она есть. TMGetLedger - это тип сообщения запроса, а TMLedgerData - тип его ответного сообщения. У них обоих есть поле requestCookie, чтобы связать ответ с его запросом. Запрос генерирует (случайный?) Идентификатор для своего «cookie запроса», а ответ копирует этот файл cook ie.
При использовании HTTP код, который отправляет запрос, проходит обработчик ожидая ответа. Как правило, обработчик ответа отличается для каждого места в коде, отправляющего запрос. Не так с RTXP. Вместо этого каждый тип сообщения запроса обычно соответствует ровно одному типу сообщения ответа, и каждое сообщение данного типа имеет один и тот же точный обработчик. Это означает, что каждое место в коде, которое отправляет запрос одного и того же типа сообщения, использует один и тот же обработчик ответа. Я подозреваю, что:
большинство типов сообщений отправляются ровно из одного места в коде
, когда один тип сообщения отправляется из нескольких мест, тогда в этом сообщении есть поле перечисления, чтобы различать guish их (с «типом» в названии)
каждый тип сообщения был разработан для того места в коде, которое необходимо отправить, что затрудняет их повторное использование
Большинство типов сообщений запроса отличаются от типов сообщений ответа. Единственным примечательным исключением является TMGetObjectByHash, в котором есть логическое поле query, которое отличает запрос (true) от ответа (false).
Есть место для единообразной обработки каждого типа сообщения:
Обычно ожидается, что сообщение будет поддающимся независимой проверке. Если в ответе говорится, что у него есть заголовок для главной книги ABCD, то обработчик ожидает, что он может иметь sh заголовок для получения дайджеста ABCD.
Обычно ответ ожидается, что соответствует запросу.
Если эти ожидания нарушаются, одноранговый узел, отправивший сообщение, наказывается. Наш сервер отслеживает «плату» за каждого однорангового узла, который измеряет его надежность. За плохие сообщения взимается различная плата в зависимости от типа нарушения. Эти сборы существуют только на сервере. Они не имеют отношения к бухгалтерской книге.
PeerImp объектов получены из объекта Overlay. Существует ровно один Overlay на Application, полученный путем вызова его метода overlay().