Yes, that is the one change I am still pondering: adding categories (classes), rather than one single bit.
Thus the modified proposal would become: - eliminate NODE_EXT_SERVICES - for a class of services, such as insight w/ added blockchain indexes & queries, add NODE_EXT_INDEXED_CHAIN - for another class of services, add NODE_EXT_xxxx - Re-use the same P2P message and structure (CExtService, "extservices" P2P message) for all NODE_EXT_xxx classes. This preserves vendor/API neutrality, while saving effort on the part of clients seeking these services. The point about service discovery necessitating some node walking is valid, which makes categories somewhat attractive. "Having the service run on some arbitrary other port isn't particularly useful, IMO" -- A statement disproved by reality. Multi-port is the method most commonly found in the field today. Logically so, because it is the easiest to deploy: * The most likely setup TODAY is multi-daemon: bitcoind + your own software * The most likely configuration for multi-daemon is self-evidently multi-port (versus two services appearing on the same port) It is quite useful, and indeed, the most likely setup to be found in operation. On Fri, Aug 8, 2014 at 7:38 AM, Mike Hearn <m...@plan99.net> wrote: > I'd like to see a mechanism whereby a Bitcoin node can delegate processing > of unknown messages to an external process, so a P2P node can be composed > out of separated programs, but such a service would be indistinguishable at > the network layer from one provided by Bitcoin Core itself, so a service bit > would be appropriate for those. > > For instance, Insight could then offer a command set that extends the p2p > protocol for doing block explorer type queries. There's no need for the > protocol to be Insight specific. You'd just have NODE_INDEXED_CHAIN > instead. > > Having the service run on some arbitrary other port isn't particularly > useful, IMO - the biggest win from having some separated protocol would be > the ability to use TLS, but if you're connecting to an IP address rather > than a domain name (like if you discovered via service bits/getextsrv) this > doesn't add much. It boils down to minor syntax differences in how numbers > are laid out in a grid. And the performance issue remains. > > Additionally, nothing in this spec requires that a local bitcoind be > running. What stops someone from advertising just NODE_EXTENDED_SERVICES and > nothing else? I don't think a generic service advertisement mechanism is a > bad thing to have, by the way, just pointing out that nothing makes this > more focused than service bits already are. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
