А что ты делаешь? В ту ММО с корабликами добавили "радио"?

сувай туда джсон и радуйся

Всё, уже точно xor.

просекут

в конце концов, атака повторения илиминтарная

да жованный конь. диффи хелман — вот вам канал. дальше аутентификауия по паблик ключам, потом обмен симметричными и AES

1. Запомни ключ на отправителе и приёмнике, будет "закрытым ключом", в идеале — добавляй в начало передаваемого сообщения какую-нибудь рандомную соль, шоб не палевно; 2. Если вопрос-ответ — то можно сделать схему а ля: > дай ключ заксоренный нашим общим секретом < держи ключ (сгенерённый) > заксоренное новым ключом сообщение < заксоренный новым ключом ответ Ну типо публик/привейт с ксором ))

1. Запомни ключ на отправителе и приёмнике, будет "закрытым ключом", в идеале — добавляй в начало передаваемого сообщения какую-нибудь рандомную соль, шоб не палевно; 2. Если вопрос-ответ — то можно сделать схему а ля: > дай ключ заксоренный нашим общим секретом < держи ключ (сгенерённый) > заксоренное новым ключом сообщение < заксоренный новым ключом ответ Ну типо публик/привейт с ксором ))

От атаки повторения защищён публик-прувейт.

если одна и та же команда одинаково в шифрованном виде выглядит то пяка

Нет, базовая команда чиста и выглядит как HELLO, ответом на неё рандомные — цифры. И ты этими цифрами должен ксорить исходящее и расксоривать входящее.

велосипед

DTLS же

можно ещё вот так: приватным ключом шифровать месадж magic|timestamp|data

Я думаю timestamp|message подошло бы

можно ещё вот так: приватным ключом шифровать месадж magic|timestamp|data

Да пофигу, запихнуть сообщение разбитое на кусчочки в тело рандомных символов, сделав маркеры начала-конца кусочка сообщения (можно несколько вариантов маркеров), и выдирать его регуляркой. И всё, уже никто не поймёт что это.

О, кстати, только что вспомнил про врЕменные токены во всяких гуглах и прочих стимах. Типа "раз в десять секунд генерируем ключ". Соответственно, твоя задача — округлить текущее время до десяти секунд и сгенерировать ключ тем же алгоритмом, каким он генерируется на приёмнике (любой хеш округлённого таймстампа) и выслать его. Для обеспечения непрерывности — можно на стороне приёмника сгенерировать три ключа: для прошлых десяти секунд, текущих, и будущих, и сравнивать пришедшее с ними: если с одним совпало, значит норм.

так работают микросервисы-)

Давай

Там где последовательная передача между 5 микросервисами

вот: https://github.com/alphallc/crappycms а вот это - подобие поинта (только мне было лень запиливать связь с базой) https://github.com/msva/xIOn

Там где последовательная передача между 5 микросервисами

Отчёт об исследованиях луёво-сишной апишки: 1. Full userdata это типа размеченный блок памяти, имеет метаметоды; 2. Light userdata — это просто указатель на какие-то сишные данные, метаметодов не имеет, даже __gc, соответственно необходимо управлять сборкой с сишной стороны. Но в full userdata можно впилить указатель на указатель, и получить типа light userdata с метаметодами.

Я себе для таких дел пару функций накидал. Получилось удобно, но не очень красиво. (Функция setup нужна, чтобы при создании юзердаты можно было в регистровую таблицу cs_data внести необходимые данные, например, сишные структуры-вектора, чтобы потом их можно было менять, при обращении к этой юзердате по средствам геттеров и сеттеров)