2016-01-30 8 views
1

В torrent client Я написал, я не принимаю соединения, если я действительно не хочу или не нуждаюсь в дополнительных соединениях. Это приводит к netstat, показывающему много SYN_RECV, что кажется правдоподобным, поскольку я еще не завершил соединение. Используют ли они доступные дескрипторы файлов на сервере? Неужели плохая практика позволяет заполнению задержек до тех пор, пока я действительно не хочу принять? Есть ли более эффективная практика?Могу ли я оставить сокеты в SYN_RECV, пока я не заинтересован в принятии?

ответ

3

№. Соединение завершено стеком TCP, возможно, задолго до того, как вы вызовете accept(), и поместите в очередь на отставание. Все, что accept() делает, блокируется, пока очередь журнала не заполнена, а затем удаляет и возвращает элемент head в виде сокета FD. Это не имеет ничего общего с подключением квитирования.

Соединения в очереди на отставание не используют дескрипторы файлов. FD выделяется accept().

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

YMMV на конкретных платформах.

+1

Я далеко от своих ссылок до завтра, но я считаю, что сокеты в состоянии SYN_RECV находятся в другой предыдущей очереди для соединений, которые не могут быть завершены, потому что очередь задержек заполнена, и я считаю, что эта очередь должна время вышло достаточно быстро. Но все это связано с тем, что вы не принимаете связи. – EJP

+0

Я с нетерпением жду ваших дальнейших ссылок, спасибо. –

+0

Может ли они в отставании ухудшать производительность системы в любом случае, предполагая нормальные параметры конфигурации? Если система завершает рукопожатие до того, как будет принято вызов, действительно ли это состояние SYN_RECV? –

1

Есть ли более эффективная практика?

Примите и немедленно закройте их, если вы временно не хотите принимать дополнительные соединения с ручкой.

Но в контексте bittorrent вы можете вместо этого реализовать BEP 40 и хотя бы выполнить рукопожатие bittorrent, чтобы увидеть, к какому рою принадлежит соединение, и следует ли отказаться от существующего в пользу нового и закрыть его если вы определили, что он имеет более низкий приоритет, чем существующие.

+0

Спасибо. Я действительно принимаю его, если есть какая-то возможность, которую я могу использовать. Если, например, все торренты на клиенте завершены, а не посеяны, у меня нет причин ничего принимать. Так как насчет этого случая? –

+0

Спасибо за ссылку на BEP40 !! Я понятия не имел, что это существовало. –

+0

принимаем & близко обычный способ. в принципе вы также можете закрыть серверный сокет, но я думаю, что немногие люди этого не делают. – the8472