Пишу программу делающую редирект TCP соединений.
Все сокеты разруливаются через системеый вызов poll одним единственным процессом. Теперь ситуация:
От серверного сокета accept-иться новый клиент, трафик от которого, мы будем редиректить. Выбирается цель на которую пойдет редирект трафика. Делаем connect на цель. допустим connect возращает EINPROGRESS, потому что адрес цели-порт недоступны. С клиентского сокета читаем данные, которые должны уйти на цель. Далее ставим сокеты клиента и цели (файловые дескрипторы) на проверку функцией poll. Клиента проеряем на POLLIN - ждем чтения без блокирования; Цель проверяем на POLLOUT - ждем записи без блокирования. Вот такая исходная ситуация, надеюсь что в общем понятно.
Далее системный вызов poll блокирует процесс ожидая либо новых данных на клиентском сокете либо возможности записать уже полученные данные в сокет цели. Допустим через пару минут цель отваливается по TCP timeout.*НО* poll вместо того чтобы в revents для него вернуть POLLHUP - A hangup has occurred on the stream, начинает возвращать POLLOUT (=4) и только его. Почему??? Дальше процесс получив информацию о том что цель готова, пытается отправить на нее данные - не получается - ставим снова на poll - poll еще раз возращает POLLOUT.. ну и так далее.. почему так происходит? почему poll не говорит о разрыве соединеия? раньше я наблюдал похожую штуку - каждый раз когда установленное TCP соединение рветься poll начинает сообщать что на этом сокете случился POLLOUT.
Alex
ICQ# 161870585
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Похожие темы
- Форум Transport endpoint is not connected (2002)
- Форум poll() (2005)
- Форум poll() (2004)
- Форум polls, links (2011)
- Форум poll() error (2005)
- Новости MySQL poll (2002)
- Форум polling & FreeBSD 8.1 (2010)
- Форум ALSA, использование poll() (2013)
- Форум poll и FIFO (2018)
- Форум poll внутри ядра (2015)