It must be possible to program libbitcoin in such a way that independent
of how fast blocks come in and thus libbitcoin tries to do disk IO,
there's no crash and burn scenario.

Just add in some kind of self-feedback so that the previous steps don't
accept more work.

There should be logics such that when libbitcoin has enough to do on its
own, this will chain-propagate in such a way that if it's real jammed,
libbitcoin stops reading from its TCP connections, and thus eventually
the TCP connection's window will be full, and the node will not be able
to push more data but will be blocked himself by his local TCP stack in
sending over more data.

And unless resuming fast enough, other peers would start to time out on
pings and close the connection - that should do for a graceful shutdown.


Outside of libbitcoin everything is in place for libbitcoin to be secure
against crash and burn scenarios, so it's just a question that lb needs
to have own internal overload protection logic too.

Might be an effort to implement of course, however, libbitcoin is
intended to be like the central core library in this kind of projects so
such an effort should be more than justified.

Thoughts?

On 2014-01-06 17:09, Noel Maersk wrote:

> On Mon, Jan 06, 2014 at 11:45:05AM +0100, mlmikael wrote:
>
>> Higher performance is always cool. However sometimes even that doesn't deliver - a high-bandwidth low-IO VPS, a server with a performance bump etc. - there's always a circumstance that could fry IO performance transitorily, and in those cases, you want libbitcoin to remain rock solid. Is this the case now?
>
> No. There are hardware setups (like the one you outlined, I'm running it
> on a VPS just like that) where libbitcoin/Obelisk are unstable. I hope
> libblockchain will fix that - otherwise, the only way is throttling,
> e.g. reducing the number of connections.
>
>> (It sounded a bit like lb catches fire if there's an IO lag this is why I asked these things - if so that would be terrible as it'd be a kind of a ticking bomb logic about it)
>
> The issue is mostly visible when downloading the blockchain from block
> 1, since there's a lot of very small blocks, and all peers have them.
>
> _______________________________________________
> Libbitcoin mailing list
> Libbitcoin@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin [1]



Links:
------
[1] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin