webtorrent/webtorrent

`maxConns` option is ignored for incoming connections

Open

#703 建立於 2016年3月29日

在 GitHub 查看
 (2 留言) (1 反應) (0 負責人)JavaScript (30,002 star) (2,748 fork)batch import
area/perfbughelp wanted

描述

The maxConns option is currently ignored for incoming connections, so there's effectively no limit the number of incoming connections that we accept.

For TCP, we could just immediately destroy the incoming connection, or perhaps pause the server somehow to avoid accepting in the first place? For WebRTC, we should consider not ever returning an offer when we're at capacity, since doing the whole signaling process is expensive (webrtc conns are a limited resource; and trackers have limited resources)

貢獻者指南

技術棧
javascript
領域
backend
議題類型
bug
難度面向新貢獻者的預計實作難度，1 表示很小改動，5 表示專家級工作。
3
預計時間有經驗貢獻者完成調查、實作、測試並準備 pull request 的粗略時間範圍。
half day
活動狀態議題目前的可參與程度：新鮮、活躍、陳舊、阻塞或等待維護者輸入。
stale
清晰度議題是否清楚說明預期改動、驗收標準和下一步。
mostly clear
前置要求
Understanding of TCP server architecturesBasic knowledge of WebRTC signaling
新手友善度1-100 的估計分數，表示該議題對首次貢獻者的友善程度。
35
研究方向
The issue describes that maxConns is not enforced for incoming connections. For TCP, investigate the server's connection handler to see where incoming connections are accepted and whether maxConns is checked before accepting. For WebRTC, look at the signaling process to understand when an offer is returned and if it can be suppressed when at capacity. Search for existing comments or related code in the repository, particularly files handling connection limits (e.g., 'lib/server.js' or similar). Evaluate whether pausing the TCP server or destroying connections immediately is feasible, and how to handle WebRTC connection capacity.