Cyclone-Team/stadium-proto
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Основа касательно потоков готова

Browse Source
This commit is contained in:
Shr3dd3r 2023-12-19 06:08:43 +03:00
parent 0c4e6cfcd1
commit 999514abec
2 changed files with 26 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.gitignore vendored
View File

@ -5,4 +5,3 @@ LBM.md
Reserved LBM keys.md
Reserved events/
Sessions.md
Streams.md

26
Streams.md Normal file
View File

@ -0,0 +1,26 @@
# Потоки
**Поток** представляет из себя канал обмена _событиями_ в определённой конфигурации. _Узлы_ должны обрабатывать _события_ единообразно, вне зависимости от того, через какой _поток_ они передаются.
## Stream ID
Каждый _поток_ имеет пару собственных уникальных идентификаторов: "Stream ID", "SID". Они используются для определения принадлежности _события_ к существующим _потокам_. Для увеличения энтропии, с целью исключения анализа траффика, SID представляет из себя нефиксированное значение, уникальное для каждого _события_. Каждый из двух _узлов_ в _соединении_ имеет собственный SID.
Допустим, что есть два _узла_: `pc`, который подключается, и `ps`, к которому подключается `pc`. Тогда пусть SID, используемый _узлом_ `pc` будет называться `sidc`, а `ps` - `sids`. Для того, чтобы установить новое _соединение_, _узлы_ должны проделать следующее:
1. `pc` генерирует стартовое значение `sidc` и отправляет его _узлу_ `ps` вместе с алгоритмами симметричного шифрования и хэширования для обработки `sids`, а также симметричный ключ соответствующего алгоритму размера.
2. `ps` принимает данные и отвечает _узлу_ `pc` стартовым значением `sids`, алгоритмами шифрования и хэширования `sidc`, а также симметричный ключ соответствующего алгоритму размера.
При этом, `ps` должен иметь единую конфигурацию алгоритмов симметричного шифрования, хэш-функции и используемый ключ для обработки SID всех _потоков_. Перед использованием в отправляемом _событии_, _узел_ должен обработать прежнее значение SID, а именно: зашифровать его с использованием избранного при установке _соединения_ алгоритма симметричного шифрования и ключа, а затем вычислить хэш. Если размер выходных данных хэш-функции больше размера SID, то эти данные поблочно XOR'ятся сами с собой. В реализации это может выглядеть вот так: <!--NOTICE: получше формализовать надо, скорее всего-->
```C
// size_t arr_sz: размер вывода хэш-функции
// char *arr: вывод хэш-функции
// uint32_t sid: прежний SID
sid = *(uint32_t*)arr;
for (size_t i = 1; i < arr_sz / 4; ++i)
sid = sid ^ ((uint32_t*)arr)[i];
```
Если любой из _узлов_ обнаруживает ложное значение SID в полученном _событии_, то он обязан разорвать _соединение_. <!--и сохранять статус _потока_ в течении времени, определяемого имплементацией и конфигурацией. _Узел_, инициировавший создание _потока_, может попробовать пересоздать его в течении этого времени, -->
<!--TODO: StreamRessurectionKey, восстановление потока в случае обрыва связи-->