linux-сокеты и многопоточность в C

Question

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

Лучше, чтобы каждая нить открывала свой собственный сокет в тот же пункт назначения, используя тот же номер порта UDP, когда поток создан (таким образом, требуется 100 отдельных дескрипторов файлов), или чтобы открыть сокет один раз в основном потоке и передать этот файловый дескриптор для каждого из потоков, чтобы каждый из них использовал один и тот же сокет? Каждый поток будет генерировать около 20 пакетов в секунду, каждый пакет длиной около 800 байт. Синхронизация между потоками отсутствует.

Answer 1

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

Answer 2

Я бы выбрал loose-coupling подход - все темы независимы. Нагрузка не кажется чрезмерной, поэтому loose-coupling представляется подходящим.

Конечно, некоторые люди не согласятся, а из систем точки-обзор, отрывная муфта всегда предпочтительнее ... где это применима :-)

Answer 3

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

Answer 4

ваше решение работает правильно, потому что у вас нет одинаковых данных для обмена между потоками. Но я думаю, вы можете использовать пул соединений (сделать некоторое соединение и заняться потоками), а потоки в очереди ждать, чтобы дать соединение из пула. Если количество соединений и поток - большая потеря производительности [ограничение сети и ограничение вашего компьютера] другое решение что в очереди все вещи не используют пул и очередь на все thing.but, я думаю, что объединение дает лучшую производительность.