Проект "Свободные голосования"

Решил сделать на вики что-то конкретное по протоколам что-бы уже как-то начинать.

Структура пакетов

Типы пакетов

Коды типов голосований

Коды данных (Грубо говоря, коды, описывающие назначение полей данных)

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Структура пакетов:
Для того чтобы через сеть могло функционировать множество подсистем необходимо ввести номер протокола. Для того, чтобы корректно разбивать поток на "пакеты" необходимо ввести длину.
Итого: Номер протокола 2 байта, длинна пакета 2 байта.
Дальнейшие данные вообще говоря для каждого из протоколов могут быть специфичными. Но в общем случае будет что-нибудь вроде "тип пакета в данном протоколе" (как в вашем варинте), можно фиксировано задать 2 байта, 1 лишний байт роли не сыграет.

Для функционирования самой сети скорее всего будут нужен собственный протокол. Предлагаю зарезервировать номера протоколов 0..15 как системные.
-------------
Системой голосований предлагаю заняться после того как будет готов транспорт.
ps не совсем понимаю необходимость в кодах данных.
pps пакеты лучше идентифицировать не по uuid а по хэшу от неизменяемых данных. (транспортная подпись является изменяемой и для идентификации пакета учитываться не должна)

_________________
AF4B DFB0 0E41 2F7A 09FD 4971 96F0 B176 EA1C DD85

1 байт не сыграет никакой роли при передаче одного пакета. При функционировании всей сети - очень даже сыграет. Я-бы и версию протокола сделал однобайтной.


Не против.


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


В некоторых пакетах могут содержаться произвольные структуры данных. Можно, конечно, попробовать обойтись и без кодов данных (это типа ключей в JSON что-бы не использовать строковые имена). Только тогда возникнет ограничение на добавление каких-то не предусмотренных системой свойств в субъекты голосований, например.


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

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Кстати, насколько я понимаю, вы протоколом называете то, что я называю "типом пакета"?

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Пример:
Протокол 0 (системный протокол транспортной подсистемы)
Тип пакета 0 (запрос открыкого транспортного ключа)
Тип пакета 1 (ответ содержащий открытый транспортный ключ)
Тип пакета 2 (запрос списка узлов в ноде)
Тип пакета 3 (список узлов в ноде)
Протокол 66 (протокол голосований)
Тип пакета 0 (запрос списка субъектов)
Тип пакета 1 (ответ списка субъектов)
и т.п.
В этом случае именно "тип пакета" определяет содержимое которое передается в нем. Я бы его даже назвал "команда", команда "REQUEST_SUBJECT_LIST", "RESPONCE_SUBJECT_LIST".

Обработка при этом производится так:
Транспортная система принимает самый маленький первый заголовок. Если "протокол" поддерживается системой то принимаются оставшиеся байты в буфер, буфер передается на обработку модулю. Модуль в зависимости от "тип пакета" методом тупого switch вызывает функцию для обработки именно этого типа пакета. Функция преобразует указатель на буфер в указатель на структуру связанную с этим типом пакета и получает нужные поля данных. Никаких кодов данных до этого момента не нужно.

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

_________________
AF4B DFB0 0E41 2F7A 09FD 4971 96F0 B176 EA1C DD85

Даже при наличии 140млн устройств это сгенерирует всего лишь 280мб лишних данных, распределенных по коммуникациям всей страны. Заголовки ip сгенерируют в 10 раз больше данных, и tcp столько же.
Можно сэкономить на UUID, в качестве хеша можно будет использовать md5 (128 бит). Да даже если использовать SHA256 это нам никак не помешает. По факту нам не надо его передавать вместе с данными . Я предполагаю что схема будет примерно следующая:
A: B, у тебя есть пакет ID123123?
B: неа
A: на данные
B: принял данные, посчитал хэш, добавил пакет в БД.
Либо возможен другой вариант:
A: B, дай мне пакет ID1234123
B: на
A: принял данные посчитал хэш, добавил в БД.

_________________
AF4B DFB0 0E41 2F7A 09FD 4971 96F0 B176 EA1C DD85

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

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Вы забываете что у нас связи будут не "один-к-одному", а "многие-ко-многим". Соответственно, эти 280Мб надо умножать на среднее количество связей у клиента.


Не вы-ли мне объясняли почему нельзя использовать md5? Кроме того, на чем вы собрались экономить если uuid и так имеет размер 128 бит (16 байт)? Кстати, присутствие в uuid MAC адреса не обязательно, если вы из-за этого против него.


Мне не нравится увеличенная нагрузка на клиента если ему придется считать хэши всех приходящих пакетов. Вообще, хэши конечно лучше в качестве идентификаторов, т.к. одновременно выполняют 2 функции - и идентификацию и контроль данных. Но для идентификации нельзя использовать md5, соответственно, размер хэша будет больше чем uuid.

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

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Уверен эта нагрузка не будет значительной.

Я согласен на sha256. При том, что передаваться это поле (см. мой пример взаимодействия устройств) будет только при необходимости.

_________________
AF4B DFB0 0E41 2F7A 09FD 4971 96F0 B176 EA1C DD85

Прикинул тут... Идентификация по хэшу от данных нам подойдет только для идентификации на низком уровне. Например, для идентификации передаваемых в сети пакетов. Для идентификации, например, субъектов, такой способ уже не подойдет, т.к. в субъекте будет присутствовать изменяемая информация. Думаю, на более высоком уровне для логической идентификации объектов нужно uuid использовать.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68