2

У меня есть сервер, который работает как несколько процессов, используя SO_REUSEPORT для обеспечения параллелизма. Однако серверному процессу может быть назначено соединение, даже если оно занято обработкой, которая эффективно выполняет однопоточные запросы. Это не похоже на документированное поведение SO_REUSEPORT.

Чтобы исключить мой код, я скачал простой TCP-сервер с https://www.cs.cmu.edu/afs/cs/academic/class/15213-f99/www/class26/tcpserver.c и изменил его следующим образом:

/* добавлено SO_REUSEPORT */setsockopt(parentfd, SOL_SOCKET, SO_REUSEADDR | SO_REUSEPORT, (const void )& optval, sizeof (int)); , , ,/ спать до закрытия */спать (10); близко (childfd);

Я запускаю 2 экземпляра этого (на одном и том же порту) в режиме strace и получаю к ним доступ с помощью скручивания с интервалом в несколько секунд. Я вижу, что второе соединение curl может завершиться в ожидании первого сервера, даже если этот сервер находится в спящем режиме, а другой сервер ожидает в accept ().

Это может показаться недостатком в реализации SO_REUSEPORT (согласно нескольким статьям семантика должна быть «реализация SO_REUSEPORT распределяет соединения равномерно по всем потокам (или процессам), которые заблокированы в accept () на том же порту».

Ядро: Linux версии 3.14.27-25.47.amzn1.x86_64 (mockbuild @ gobi-build-60001) (версия gcc 4.8.2 20140120 (Red Hat 4.8.2-16) (GCC)) # 1 SMP ср. 17 декабря 18: 36: 15 UTC 2014

0