📅 Original date posted:2012-08-17
📝 Original message:On Fri, Aug 17, 2012 at 9:40 AM, Pieter Wuille <pieter.wuille at 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.
jgarzik at exmulti.com
Jeff Garzik [ARCHIVE] /
npub1kf…f3f58
2023-06-07 10:29:09
in reply to nevent1q…afsh
Author Public Key
npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58Published at
2023-06-07 10:29:09Event JSON
{
"id": "2551188b5a90c93bddf563c1d55b77bff9ed4ddd98c341200eabd40003146087",
"pubkey": "b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11",
"created_at": 1686133749,
"kind": 1,
"tags": [
[
"e",
"230151bb9ac0f5af1d29fc832b378f46a6a5a710d215c859a985fc5e0d75bc92",
"",
"root"
],
[
"e",
"b3e2900d68de160bd84db5a5169b1b1c1a4e181683ddd02146f2ea11b776fd79",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2012-08-17\n📝 Original message:On Fri, Aug 17, 2012 at 9:40 AM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003e wrote:\n\u003e On Thu, Aug 16, 2012 at 05:05:58PM -0400, Jeff Garzik wrote:\n\u003e\u003e On MSG_MEMTX: The current version has a much higher Just Works value.\n\u003e\u003e\n\u003e\u003e On empty \"inv\": It is generally better to do something\n\u003e\u003e unconditionally, than have a response generated only under certain\n\u003e\u003e conditions.\n\u003e\u003e\n\u003e\u003e And Alan is correct to note that unknown messages are ignored\n\u003e\u003e (intentionally, for expansion). However, unconditionally returning a\n\u003e\u003e response has little to do with feature probing/discovery. It is\n\u003e\u003e simply a clear, deterministic indication that processing is complete,\n\u003e\u003e for each invocation.\n\u003e\n\u003e I disagree. Returning an empty \"inv\" is a very strange way of replying\n\u003e \"empty mempool\". Bitcoin P2P is not a request-response protocol, and\n\u003e \"inv\" messages are sent where there are inventory items to send. The\n\u003e reaction to a request (for example \"getblocks\") can be nothing, or one\n\u003e or more \"inv\" messages if necessary. Special casing an empty \"inv\" to\n\u003e mean empty mempool is trying to hack a request-response system on top\n\u003e of the asynchronous system.\n\nOK, just updated 'mempool' branch to not return \"inv\" if mempool is empty.\n\n\n\u003e If there is need for confirming the transmission of the mempool is\n\u003e complete, the proposal to use a MSG_MEMTX sounds good to me. No client\n\u003e will ever receive such an inv without requesting the mempool, and\n\u003e implementing handling MSG_MEMTX is trivial.\n\nMSG_MEMTX is not a good idea for this use case. Just sent a ping(nonce).\n\nBitcoin P2P processes requests in-order, and responds accordingly.\nThe remote end may insert asynchronous messages into the response\nstream, certainly, but responses to queries are processed and returned\nin-order. A 'getdata' response is fully sent before a 'ping' response\nis sent, etc.\n\n-- \nJeff Garzik\nexMULTI, Inc.\njgarzik at exmulti.com",
"sig": "0b57af82bc00742c51221b56c758b3ad23c8ea5ea6c5fd5c1cc0c7e310c6b905bfcf2b134f191419577e179684f6529989f45549890e3f9b749fac22c3b5e303"
}