один двунаправленный сокет tcp ИЛИ два однонаправленных? (Linux, большой объем, низкая задержка)

Question

Мне нужно периодически отправлять (обмениваться) большой объем данных с минимально возможной задержкой между двумя компьютерами. Сеть довольно быстрая (например, 1Gbit или даже 2G +). Os - это Linux. Это быстрее с использованием 1 TCP-сокета (для отправки и получения) или с помощью двух однонаправленных TCP-сокетов?

Тест для этой задачи очень похож на сетевой тест NetPIPE - измеряет задержку и пропускную способность для размеров от 2 ^ 1 до 2 ^ 13 байт, каждый размер отправляется и принимается как минимум 3 раза (в задаче teal количество отправлений равно больше. оба процесса будут отправлять и получать, как, например, пинг-понг).

Преимущество 2 однонаправленных подключений происходит от Linux:

http://lxr.linux.no/linux+v2.6.18/net/ipv4/tcp_input.c#L3847

3847/*
3848 *      TCP receive function for the ESTABLISHED state. 
3849 *
3850 *      It is split into a fast path and a slow path. The fast path is 
3851 *      disabled when:
...
3859 *      - Data is sent in both directions. Fast path only supports pure senders
3860 *        or pure receivers (this means either the sequence number or the ack
3861 *        value must stay constant)
...
3863 *
3864 *      When these conditions are not satisfied it drops into a standard 
3865 *      receive procedure patterned after RFC793 to handle all cases.
3866 *      The first three cases are guaranteed by proper pred_flags setting,
3867 *      the rest is checked inline. Fast processing is turned on in 
3868 *      tcp_data_queue when everything is OK.

Все остальные условия отключения быстрого пути ложны. И только не-однонаправленный сокет останавливает ядро ​​от fastpath при получении

Answer 1

Слишком много переменных для одного ответа, чтобы всегда держать здесь. Если у вас нет очень очень быстрого сетевого соединения - вероятно,> 1 Гбит / с на современном оборудовании - то, что вы связали с быстрым или медленным путем, вероятно, не имеет значения.

На всякий случай, вы можете написать свою программу для работы в любом случае. Просто сохраните readsocket и writeocket, и во время connect () вы можете назначить им один и тот же сокет или два разных сокета. Тогда вы можете просто попробовать оба способа и посмотреть, какой из них быстрее.

Весьма вероятно, что вы не заметите никакой разницы между ними.

Answer 2

Я знаю, что это не отвечает непосредственно на ваш вопрос, но я бы посоветовал взглянуть на что-то вроде ZeroMQ . Об этом есть вводная статья на lwn: 0MQ: Новый подход к обмену сообщениями .

Я еще не пробовал, но я немного прочитал об этом, и, похоже, это то, что вы ищете. Зачем изобретать велосипед?