Кто быстрее: сURL или сокеты (С++)?

быстрее

HTTP

Или даже другой протокол использовать...

Да, и еще: посоветуйте протокол под такие цели?

Если пишешь сервер, то учти, что libcurl позиционируется как клиентская библиотека

Ну тогда тем более cURL отменяется. Хм... что тогда использовать?

Например, сокеты + libev или что-то подобное + опционально лиюу для разбора твоего протокола

О! А libev - это хорошая идея! Спасибо.

Хз, что из протоколов под такие цели подойдет. Пока что ищу минусы у SSH.

Судя по описанию, тебе нужно что то вроде этого или этого.

Однако, на самом деле без ответа на вопрос - сколько сообщений в секунду тебе нужно? Всё это пустой трёп.

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

необходимо не более 100 сообщений в секунду по очень зашумленному каналу (SNR около 1 дБ) с использованием шифрования.

иными словами, около 5 мегабит в секунду.

curl - просто «обётртка», и, как следствие, сокеты будут «быстрее».

сокеты + json

zmq/nanomsg

Отлично. Ты знаешь требования.

Дальше берёшь - и пишешь тест :)

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

Можно написать примерно такой тест - прогнать столько udp, заданного размера сообщений сколько влезает в канал(благо оно с запасом туда умещается, если mtu стандартный). Посмотреть сколько удалось всунуть и сколько дошло.

Потом тоже самое провернуть с tcp.

Посмотреть среднюю скорость долетания сообщения.

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

Если у тебя не мк и не IPoAC, то можно выбрать то, где интерфейс больше нарвится.

Вообще, сокеты плюс libev или вручную, будут быстрее курла, но не факт что это будет узким местом. И быстрее они будут (в смысле ощутимо быстрее), только если ты всё правильно запилишь. Точнее, правильней, чем разработчики курла :) С другой стороны, curl тоже можно криво заюзать наверное.

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

И алыверды - а почему ssh, а не ssl?

Вообще, вот такое утверждение нашёл:

A ratio of 10-15dB is the accepted minimum to establish an unreliable connection;

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

Без тестов всё равно сложно сказать, но скорее всего это должно быть что то udp/based, возможно ещё ниже придётся копнуть :) Сильно зависит от того - сколько таки бит можно передать с хоть сколько то высокой вероятностью.

Сокет, возможно, даст какой-то выигрыш.

Что за бред? Управляющий протокол ftp - telnet, так что для него ищи библиотеку.

А что, curl сокетами не пользуется, через астрал байты передает?

Он наверное предполагает, что http-протокол внесет оверхед, если в него завернуть его велосипедный обмен сообщениями по протоколу ftp

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

A ratio of 10-15dB is the accepted minimum to establish an unreliable connection;

это если по вайфаю. А если требуется максимально снизить энергопотребление, то Bluetooth 4.0 подойдет. Один фиг - дальше 100 метров редкая сеть бьет. Плюс, если требуется работа устройства во время дождя/около водоема в пасмурную погоду, то там куда меньше 100 метров будет: максимум спектра поглощения воды находится в пределах 2,4-2,5 ГГц. Это тот самый диапазон, на котором работают вайфаи, блютузы и... микроволновки.

Ну тут вроде один способ: накапливать статистику по принятым пакетам.

Так. cURL тут уже вообще пошел лесом.

Дошли до того, что придется работать в другом диапазоне частот, чтобы повысить SNR. Значит, еще и протокол канального уровня надо менять. Какие протокола канального уровня из стандартных в случае низкого SNR подойдут?

не. тут не udp/based. тут другой канальный протокол + tcp.

libuv тогда уж.