__alekcvpПочитал тут про ZMQ и возник один вопрос по безопасности: вот в обычном TCP, как было сказано в начале статьи, в случае если нам передали неверный заголовок сообщения мы можем либо сбросить подключение вообще, либо прочитать испорченные данные в /dev/null и приступить к обработке следующего сообщения.
А вот вопрос: какова будет реакция ZMQ, если злоумышленник, зная его протокол, попытается передать валидный пакет, объемом 100500 гигабайт (объёмом, гарантированно большим чем оперативная память + своп на сервере)?
Можно ли как-нибудь лимитировать допустимый размер сообщений?

1. Тебя не смущает неоднократное упоминание того, что ZMQ - для "внутреннего" использования? В рамках локальных сетей, или отдельного компа (для межпроцессного взаимодействия) или даже для внутрипроцессного межнитевого взаимодействия. Откуда возьмутся злоумышленники?
1.1. Про новые возможности ("работа в открытых сетях") я знаю совсем немного, но они появились, например, средства аутентификации.
2. "Сбросить" соединение нельзя, можно пересоздать сокет, что и рекомендуется для разных случаев, например, когда слишком много входящих соединений "зависло" (т.е., клиент подключился, поработал и у шел), сие один из паттернов использования zmq.
3. Да, можно установить опции сокета, ограничив размер сообщения и/или буфера под сообщения: http://api.zeromq.org/4-0:zmq-setsockopt.

s62alekcvp,

так ZeroMQ это же обычная библиотека поверх TCP. Наверняка можно и размер лимитировать, и заголовок проверять и т.д.
Не, нельзя.
И tcp - лишь один из протоколов, которые может использовать zmq.

Ну да, есть там средства мониторинга ("это кто там подключился?" и т.п.), но zmq как раз для того, чтобы работать атомарными сообщениями: отправляешь сообщение (кадр или несколько кадров данных), и всё, на стороне приема они либо получены либо нет.
Кадр - всего лишь блок ТВОИХ данных, без каких-либо заголовков, длиной от 0 до 2^61-1 байт, дальше фантазируешь сам.

В общем, если тебе нужны сокеты Windows - не нужно искать их в zmq, это другой уровень.

alekcvpТ.е. она не умеет даже определять "отвалившиеся" сокеты? Или имеется в виду что "ушел" он оставив запущенное приложение?

Имеется в виду, что "она" даже не знает, приконнектился кто-то или нет.
Все, что есть - это работа с сообщениями.

Ждешь сообщение - получил - обработал. Всё. :)

alekcvpkealon(Ruslan),

Да, я понял, походу для моей системы, где кроме самого сообщения необходимо знать ещё и от кого оно пришло, эта штука не подходит.
Ну так добавь в сообщение кадр с нужной инфой.
Ты думаешь, "чистые" tcp сокеты на приеме волшебным образом эту инфу получают? Нет, ее с передающей стороны присылают. :)

alekcvpчччД__Ну так добавь в сообщение кадр с нужной инфой.
Ты думаешь, "чистые" tcp сокеты на приеме волшебным образом эту инфу получают? Нет, ее с передающей стороны присылают. :)
В "чистом" TCP адресат привязывается к соединению, а тут мало того что придётся передавать информацию в каждом сообщении, так ещё и придумывать какой-то механизм защиты от её подмены.

Я фигею, дорогая редакция - (с).

Дело твое, конечно, но решение всех твои "проблем" отлично описаны в открытых источниках по ZMQ - и механизмы защиты, и методы идентификации, и обеспечения устойчивой связи.

А если ты хочешь от zmq получить функционал нижнего уровня - то вообще непонятно, нафига тебе ZMQ.

И, если ты думаешь, что tcp пакет сложно подменить пятью строчками кода - то заодно передавай от меня привет Деду Морозу.

alekcvpчччД__А если ты хочешь от zmq получить функционал нижнего уровня - то вообще непонятно, нафига тебе ZMQ.
И, если ты думаешь, что tcp пакет сложно подменить пятью строчками кода - то заодно передавай от меня привет Деду Морозу.
Нет, функционал мне как раз нравится, но не хватает однозначной идентификации от кого пришло сообщение. Надо будет почитать.

Да, расскажи как пятью строчками подменить обратный адрес в tcp-пакете, а потом получить на него ответ на свой адрес? :)


"Пятью строчками" не подменить, да, лишку сболтнул.

А что ты подразумеваешь под "однозначной идентификацией", конкретно?

alekcvpчччД__"Пятью строчками" не подменить, да, лишку сболтнул.
А что ты подразумеваешь под "однозначной идентификацией", конкретно?
Ну, грубо говоря, после accept() и прохождения идентификации клиента ты можешь полученный сокет использовать как идентификатор клиента, т.е. сервер всегда знает от какого клиента пришло сообщение и может у себя хранить некоторые "характеристики" этого клиента, ассоциированные с ним (через сокет). И "подменить пакет" довольно сложно, т.к. это придётся делать на уровне ip-пакетов и, не вдаваясь в подробности, это довольно геморно.

Ну и тут сокеты идентифицируются, если нужно. Если используешь пару сокетов типа REQ-REP, то сервер ВСЕГДА отправляет ответ тому, кто послал запрос, со стороны программиста вообще никаких действий не нужно, просто возвращаешь ответ в тот же сокет, откуда пришел запрос. Тут (без твоего участия) сообщение автоматически дополняется кадром идентификации (по умолчанию - случайное число), этот кадр отсекается перед передачей в обрабатывающий код, а потом автоматически дополняется при отсылке ответа.

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

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

alekcvp,

ну вот я клиент, создал сокет, задал ему в качестве идентификатора, например случайное 64-битное число.
Сервер, получив от меня сообщение, будет всегда отправлять ответ мне же, используя этот же идентификатор (часть сообщения).
Что тут можно подменить и с какой целью, конкретно?

alekcvp,

я так понимаю, что ты желаешь получить ip адрес "той стороны"?

ZeroMQ создавался, чтобы в т.ч. и спрятать от тебя процесс управление соединениями, чтобы ты сосредоточился именно на обмене сообщениями. Это самое управление соединениями включает в себя в том числе и автоматическое переподключение, что запросто может привести к изменению IP-адреса, а сокет zmq, подключенного с другой стороны, будет тот же самый. Т.е., даже если ты сможешь из нутра ZeroMQ вытянут IP-адрес удаленного корреспондента, совершенно нет гарантии, что этот адрес не изменится в процессе работы.

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

Или тебе не ip-шник нужен?

alekcvpчччД__Что тут можно подменить и с какой целью, конкретно?
Например, после это клиент может попытаться отправить серверу сообщение с другим ID, прикидываясь другим клиентом. Как он узнает этот "другой ID" мы пока оставим за скобками.

Не-не-не. Нужно определиться, что за вид атаку мы отражаем, а потом уже бороться со злоумышленниками.
...
Касаемо твоего случая - сервер будет "думать", что у него два клиента...и?

alekcvpчччД__alekcvp,
Или тебе не ip-шник нужен?
Мне нужна двусторонняя связь, правда "наоборот": есть сервер, к нему подключаются клиенты, он им рассылает сообщения, они на них отвечают. Всё. Ключевой момент: нельзя допустить чтобы какой-то клиент имел возможность отвечая на сообщение прикинуться другим клиентом.

Если один клиент прикинется другим клиентом (уже существующим, подключенным), то сервер будет слать сообщения им по очереди (такая логика ZMQ). Если я ничего не путаю. Т.е., скорее всего, получится фигня на стороне клиента.
Сие очень легко проверить.
...
Если студенты не "под присмотром" ментора - что им мешает не менять свой адрес, а просто ответить за другого? А если под присмотром - в чем проблема?