Oops, hit send too early.
Besides, prioritisation isn't very hard. Nodes can just hand clients a
> signed timestamp which they remember. When re-connecting, the signed
> timestamp is handed back to the node and it gives priority to those with
> old timestamps. No state is required on the node side. Signing and checking
> can be passed onto the general ECDSA thread pool that works its way through
> pending signature operations, they'd be prioritised lower than checking
> blocks/broadcasts.
>
The other nice thing about this approach, besides being stateless on the
server side, is that it's up to the client whether or not they present the
cookie. So the node can say "if you don't present your cookie I'm going to
disconnect you" but when the node has sufficient resources, it'd just not
request this and the client remains anonymous. If the client thinks the
server is calling its bluff, it can just wait and see if it really does get
disconnected and if so, present the cookie up front next time.
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
