Может ли следующее однопоточное клиентское приложение UDP выиграть в производительности от использования epoll по сравнению с простым вызовом recvfrom / sendto на неблокирующих сокетах?
Позвольте мне объяснить клиенту.
Я пишу однопоточный клиент на основе UDP (пользовательский протокол), который отправляет и получает данные, используя неблокирующий ввод-вывод, и мой коллега предложил использовать для этого epoll.
Клиент отправляет и получает несколько пакетов информации, все из которых связаны с уникальным идентификатором сеанса, и несколько сеансов могут выполняться одновременно.
Если я использую epoll, будет ограниченное количество файловых дескрипторов, возможно, 10-20, которые epoll_wait может ожидать. Каждый дескриптор файла будет связан с одним сеансом. Так что это максимум 10 - 20 сеансов, и это число будет применено.
Каждый сеанс имеет свой собственный конечный автомат. Из одного потока мне нужно достаточно часто запускать каждый конечный автомат и опрашивать соответствующий сокет.
В моем случае мне пришлось бы использовать epoll_wait с тайм-аутом, равным нулю, или с очень небольшим значением, чтобы я мог дать процессорное время для запуска конечных автоматов для каждого сеанса.
Если есть данные для сеанса, их нужно направить в связанный конечный автомат.
Однако я не вижу особой выгоды от такого дизайна с таким небольшим количеством файловых дескрипторов.
На мой взгляд, у меня есть два варианта дизайна:
1. В моем основном цикле, использующем epoll, я могу опрашивать дескрипторы, используя epoll_wait, либо с небольшим тайм-аутом, либо без тайм-аута.
То, как он обрабатывает данные в этот момент, - это то, где я немного застреваю ... либо я читаю это сразу, а затем выбрасываю в очередь для каждого конечного автомата, чтобы забрать его при запуске, или я устанавливаю Отметьте на конечном автомате, чтобы сообщить, что данные ожидают, и когда конечный автомат запустится, он получит их с вызовом recvfrom. Или я читаю данные и сразу же обрабатываю их и запускаю конечный автомат.
Или ...
2. Просто запустите каждый конечный автомат из основного цикла и вызовите recvfrom. Если я получу некоторые данные, обработайте это. Если я не буду делать то, что еще требует машина состояний. Существуют ли огромные накладные расходы на вызов recvfrom при отсутствии данных?
С прохождением маршрута epoll я кодирую в некоторой дополнительной сложности. Если есть большая вероятность, что в моем случае это будет быстрее, я начну это делать. Однако, если второй способ, который действительно прост, работает так же хорошо, я бы не использовал epoll.
Есть мысли?