On Fri, Aug 17, 2012 at 9:40 AM, Pieter Wuille <pieter.wui...@gmail.com> 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. jgar...@exmulti.com ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
