Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2014-08-08 📝 Original message:> > He wants to use it to ...
📅 Original date posted:2014-08-08
📝 Original message:>
> He wants to use it to advertise services that are not part of the P2P
> protocol itself, but run on a different port. Reserving services bits
> for those is not acceptable.
>
Why not? Does the port matter much?
> All the NODE_EXT_SERVICES bit does is advertise the P2P "getextsrv"
> command to get information, such as the port to connect on, for the
> auxilary service.
Yes, I understand what it does, but from a clients perspective what it
means is if someone implements a useful service and exposes it this way you
have to seek out, connect to and interrogate every possible server even if
(say) only a handful actually provide it. The most there's >1 "ext service"
the protocol becomes extremely slow, vs service bits where you can download
addr packets and see which IPs are advertising which services.
I don't see much reason to take a potentially large performance hit when
there's a service advertisement mechanism that already works. What's wrong
with the existing mechanism exactly?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140808/82a3c8bf/attachment.html>;
📝 Original message:>
> He wants to use it to advertise services that are not part of the P2P
> protocol itself, but run on a different port. Reserving services bits
> for those is not acceptable.
>
Why not? Does the port matter much?
> All the NODE_EXT_SERVICES bit does is advertise the P2P "getextsrv"
> command to get information, such as the port to connect on, for the
> auxilary service.
Yes, I understand what it does, but from a clients perspective what it
means is if someone implements a useful service and exposes it this way you
have to seek out, connect to and interrogate every possible server even if
(say) only a handful actually provide it. The most there's >1 "ext service"
the protocol becomes extremely slow, vs service bits where you can download
addr packets and see which IPs are advertising which services.
I don't see much reason to take a potentially large performance hit when
there's a service advertisement mechanism that already works. What's wrong
with the existing mechanism exactly?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140808/82a3c8bf/attachment.html>;