From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass (mailfrom) smtp.mailfrom=irif.fr (client-ip=2001:660:3301:8000::1:2; helo=korolev.univ-paris7.fr; envelope-from=jch@irif.fr; receiver=) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by mail.toke.dk (Postfix) with ESMTPS id AEE097C755C for ; Fri, 8 Jan 2021 14:19:10 +0100 (CET) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 108DJ93w004107; Fri, 8 Jan 2021 14:19:09 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 1C833EF3C3; Fri, 8 Jan 2021 14:19:09 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id j8zIidId1BUj; Fri, 8 Jan 2021 14:19:07 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 06D12EF3C1; Fri, 8 Jan 2021 14:19:06 +0100 (CET) Date: Fri, 08 Jan 2021 14:19:06 +0100 Message-ID: <87wnwn7eid.wl-jch@irif.fr> From: Juliusz Chroboczek To: Michael =?ISO-8859-1?Q?Str=F6der?= In-Reply-To: <59143aab-df95-92d8-db78-3129c2e02fb4@stroeder.com> References: <0-dxBS5LC_odE5dSkuOGwoOb2FmQ7PYcbBgSGpmtz2R1ek9xklqHKQ6UCO11J1JvU5np1csOcujLTfM3ZU_48ub3yZ1EQRcYuTbarD6EkN4=@protonmail.com> <87turv78ed.wl-jch@irif.fr> <87v9cba11z.fsf@toke.dk> <59143aab-df95-92d8-db78-3129c2e02fb4@stroeder.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 08 Jan 2021 14:19:09 +0100 (CET) X-Miltered: at korolev with ID 5FF85BCD.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5FF85BCD.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5FF85BCD.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Message-ID-Hash: XVJ6ZNHSQ325RIN47XEVOSDJKKN2HRDC X-Message-ID-Hash: XVJ6ZNHSQ325RIN47XEVOSDJKKN2HRDC X-MailFrom: jch@irif.fr X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: "galene@lists.galene.org" X-Mailman-Version: 3.3.2 Precedence: list Subject: [Galene] Re: Websocket close 1006 (abnormal closure): unexpected EOF List-Id: =?utf-8?q?Gal=C3=A8ne_videoconferencing_server_discussion_list?= Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: >> I just normally put >> >> proxy_read_timeout 1200s; >> proxy_send_timeout 1200s; > 20min? Really? Even 120s would be quite long. I've reduced the keepalive timeout to be 45 to 55s (depending on how the timer gets scheduled), even though I rather agree with Toke. Scratch that, Toke is not radical enoough: the default timeout for WebSockets should be 2 hours 4 minutes, for consistency with RFC 5382 REQ-5. WebSocket is layered over TCP. TCP indicates that a connection is closed by sending explicit FIN segments in both directions: both the client and the server explicitly close the connection. The reverse proxy should assume that the server performs its own timing out of idle clients, and only close the client connection when the server has closed its side. If the server crashes, the OS will close the connection. If the server's OS crashes, then the client will timeout the connection. The only case when the timeout is needed is when both the server and the client have left the network without closing their connections -- and in this rare case, a large timeout is good enough. The tradition to use small timeouts comes from Apache, which used to use up a whole process for every connection, even when idle. There is no reason I can see to do the same with nginx, which is only limited by the number of available file descriptors. -- Juliusz