From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1T2Pls-0001wk-ET for bitcoin-development@lists.sourceforge.net; Fri, 17 Aug 2012 16:51:40 +0000 X-ACL-Warn: Received: from mail-qa0-f54.google.com ([209.85.216.54]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1T2Plr-00024k-FE for bitcoin-development@lists.sourceforge.net; Fri, 17 Aug 2012 16:51:40 +0000 Received: by qatn12 with SMTP id n12so2005159qat.13 for ; Fri, 17 Aug 2012 09:51:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=TBXCpVNJtm8VuhCTs1yhqj9wXlFxJNzceOt5neO9whE=; b=i3KtQPeJFFUSCLRoC03Aoykl1iJtDWBjJjEP1s0xkwBZ6Ue05Wc2QZBKDPfSrJ36UV d1oTCpPyCtKw/MsxrMXHQMwgqMOTyL3XsXdySssxGYBA+VXdF5McZipTROLV6YtxEwpr /MY+xO38ts7ILqOQ83As2tw1zUib46pCWERcgwCppeYZ9jGgXvIDBH6bnbk5JZ3ep60u KJZK7H0Ruw6r50IXC0V3ufpm8to3NKNjo+kNvqj8n0mSka5pJKLnYqhV3YerLIK8dtkb nFLNaskalkFZ755AAbmYMj3OC9ya9D9I+6gUmhPIrNNOjyci+fiee+U07keMXY04DG2r gOIg== MIME-Version: 1.0 Received: by 10.229.135.149 with SMTP id n21mr4104782qct.131.1345222293823; Fri, 17 Aug 2012 09:51:33 -0700 (PDT) Received: by 10.49.97.6 with HTTP; Fri, 17 Aug 2012 09:51:33 -0700 (PDT) X-Originating-IP: [2001:4830:1603:2:21c:c0ff:fe79:c8c2] In-Reply-To: <20120817134000.GA30465@vps7135.xlshosting.net> References: <20120816175637.GA13454@vps7135.xlshosting.net> <502D482A.2090609@justmoon.de> <1345150660.5139.YahooMailNeo@web121003.mail.ne1.yahoo.com> <20120817134000.GA30465@vps7135.xlshosting.net> Date: Fri, 17 Aug 2012 12:51:33 -0400 Message-ID: From: Jeff Garzik To: Pieter Wuille Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQllJAU4zB+15iHJTFcSkL5UCCZEK4TUcxvps/jsFTsY4efOQ7Pc7DVsErKUL4NmU2lnszGw X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1T2Plr-00024k-FE Cc: Bitcoin Development Subject: Re: [Bitcoin-development] BIP 35: add mempool message X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 16:51:40 -0000 On Fri, Aug 17, 2012 at 9:40 AM, Pieter Wuille wrote: > On Thu, Aug 16, 2012 at 05:05:58PM -0400, Jeff Garzik wrote: >> On MSG_MEMTX: The current version has a much higher Just Works value. >> >> On empty "inv": It is generally better to do something >> unconditionally, than have a response generated only under certain >> conditions. >> >> And Alan is correct to note that unknown messages are ignored >> (intentionally, for expansion). However, unconditionally returning a >> response has little to do with feature probing/discovery. It is >> simply a clear, deterministic indication that processing is complete, >> for each invocation. > > I disagree. Returning an empty "inv" is a very strange way of replying > "empty mempool". Bitcoin P2P is not a request-response protocol, and > "inv" messages are sent where there are inventory items to send. The > reaction to a request (for example "getblocks") can be nothing, or one > or more "inv" messages if necessary. Special casing an empty "inv" to > mean empty mempool is trying to hack a request-response system on top > of the asynchronous system. OK, just updated 'mempool' branch to not return "inv" if mempool is empty. > If there is need for confirming the transmission of the mempool is > complete, the proposal to use a MSG_MEMTX sounds good to me. No client > will ever receive such an inv without requesting the mempool, and > implementing handling MSG_MEMTX is trivial. MSG_MEMTX is not a good idea for this use case. Just sent a ping(nonce). Bitcoin P2P processes requests in-order, and responds accordingly. The remote end may insert asynchronous messages into the response stream, certainly, but responses to queries are processed and returned in-order. A 'getdata' response is fully sent before a 'ping' response is sent, etc. -- Jeff Garzik exMULTI, Inc. jgarzik@exmulti.com