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. 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. -- Pieter ------------------------------------------------------------------------------ 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
