2010-04-24 6 views
1

Мне нужно периодически посылать большой объем данных с минимально возможной задержкой между двумя машинами. Сеть довольно быстрая (например, 1 Гбит или даже 2G +). Os - linux. Быстрее ли с использованием 1 tcp-сокета (для отправки и recv) или с использованием 2 однонаправленных сокетов tcp?один двухсторонний разъем tcp ИЛИ два однонаправленных? (linux, большой объем, низкая латентность)

Тест для этой задачи очень похож на сетевой тест 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. 

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

+0

Привет, вы можете проверить счет использования быстрого пути с заголовком пакетов 'netstat -s' param', который был спрогнозирован и непосредственно поставлен в очередь пользователю' aka 'NET_INC_STATS_BH (LINUX_MIB_TCPHPHITSTOUSER); ' – osgx

ответ

1

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

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

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

+0

Я заинтересован в активации быстрого пути. Проверенное аппаратное обеспечение является встроенным, но сеть работает быстро для этого оборудования. Разница здесь, как и для латентности пинг-понга (round robin), любая медлительность сделает результат меньше. – osgx

+0

Проверьте это в любом случае. Вы, наверное, не заметили никакой разницы. – apenwarr

0

Я знаю, что это не отвечает прямо на ваш вопрос, но я бы предложил взглянуть на что-то вроде ZeroMQ. На ней есть вступительная статья об этом: 0MQ: A new approach to messaging.

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

+0

Он использует 1 двухсторонний tcp. Мне нужно реализовать одну вещь самостоятельно, без каких-либо дополнительных слоев из какого-либо проекта. – osgx

+0

Он также использует дополнительные потоки. но использование потока заставит ядро ​​планировать их ввод и выход. Межпоточный контекстный переключатель будет потреблять время, которое можно потратить на полезные задачи. – osgx