2013-05-02 1 views
0

У меня есть приложение, которое, когда оно имеет данные для передачи, использует epoll, чтобы узнать, может ли данный TCP-сокет быть записан.Имеет ли epoll экспоненциальный откат?

То, что я наблюдаю, заключается в том, что по мере того как дальний конец TCP-соединения отстает, и буфер отправки сокета TCP начинает заполняться, частота, с которой epoll возвращает событие EPOLLOUT, испытывает экспоненциальное отсрочку. Такое поведение происходит до получения EAGAIN из записи сокета.

Приложение использует EPOLLONESHOT и делает вызов EPOLL_CTL_MOD для повторного включения события EPOLLOUT после каждого события. Но, как я уже отмечал выше, каждое последующее появление экспоненциально позже (у меня было прогрессирование 40 мс, 80 мс, 160 мс, 320 мс, 640 мс, 1280 мс и т. Д.) Вплоть до EAGAIN.

Это недокументированная особенность эпохи? Может ли он быть отключен? Это проблема, потому что данные становятся устаревшими, и я предпочел бы отказаться от нее, а не отправлять ее позже.

Заранее спасибо.

+0

Если устаревшие данные являются проблемой, используйте UDP, а не TCP; поэтому были изобретены два протокола. – msw

ответ

1

Нет, но TCP делает. epoll() блокировки не более указанного вами таймаута, а не минуты дольше.

+0

Да, и тайм-аут работает нормально. Проблема в том, что событие EPOLLOUT каким-то образом влияет на откат TCP. Помните, что мое приложение еще не получило результат EAGAIN от записи, поэтому нет никаких признаков перегруженности, но событие EPOLLOUT для следующей записи становится экспоненциально замедленным. – user1715587

+0

Я не понимаю, почему вы используете 'epoll()' вообще, когда буфер отправки не заполнен. Просто напиши. Вы должны только перейти к 'epoll()' * после *, вы получите * EAGAIN *, и прекратите использовать его, когда это прекратится. – EJP

+0

Да, я уже рассмотрел это изменение. Однако это не тривиально. Вместо альтернативной реализации я бы очень хотел понять, почему это поведение происходит в первую очередь. – user1715587