Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 95F42BF5 for ; Mon, 6 Mar 2017 22:21:47 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 4469D147 for ; Mon, 6 Mar 2017 22:21:47 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:a45d:823b:2d27:961c]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 2041B38ABEB7; Mon, 6 Mar 2017 22:21:25 +0000 (UTC) X-Hashcash: 1:25:170306:bitcoin-dev@lists.linuxfoundation.org::pyJsHMAuN1=kwb9D:PABH X-Hashcash: 1:25:170306:tim.ruffing@mmci.uni-saarland.de::PSXCeGIicu/csqMK:bUerq From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, Tim Ruffing Date: Mon, 6 Mar 2017 22:21:24 +0000 User-Agent: KMail/1.13.7 (Linux/4.4.45-gentoo; KDE/4.14.28; x86_64; ; ) References: <201703040827.33798.luke@dashjr.org> <1488837256.2134.1.camel@mmci.uni-saarland.de> <1488837773.2134.3.camel@mmci.uni-saarland.de> In-Reply-To: <1488837773.2134.3.camel@mmci.uni-saarland.de> X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201703062221.25169.luke@dashjr.org> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Currency/exchange rate information API X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 22:21:47 -0000 On Monday, March 06, 2017 10:02:53 PM Tim Ruffing via bitcoin-dev wrote: > For longpolling, maybe we would like to have the possibility to request > some periodic message from the server. Otherwise clients cannot > distinguish between the situations 1. "value is still in the requested > bounds (minrate, maxrate)" and 2. "connection has dropped". So the user > may take a wrong decision because he assumed that the value is still > in bounds holds but actually the server has died. That's the job of TCP. Do you think we need to explicitly specify a keepalive configuration? Seems like that would vary based on client or network.