Use unbounded channels to avoid dropped requests#335
Conversation
The `UnboundedSender` offers two advantages over bounding the number of requests a client can make. First it drops the need to maintain an `async` and sync version of the client methods - `UnboundedSender::send` is synchronous. This is actually very convient for `ldk-node`, where the client will have to implement a synchronous trait. Secondly there are some methods that are critical to succeed if the node is running. Adding a script must always work if the node is still online. Because it is unacceptable to miss some messages, there is basically two approaches: cache the failures and try again later, or use an unbounded channel. Since caching the failures will result in the exact same overhead as stored messages in a channel when the node is not ready to accept them yet, the unbounded channel is much easier to implement and reason about.
|
This interface looks good to me, so first point makes sense. But I'm not following the second. Does this change make anything more reliable? Seems like it just removes back pressure (which seems fine in this scenario). |
|
I incorrectly recalled this as a problem for the mpsc receivers but it is actually a |
|
Aren't bounded and unbounded exposed to the same types of send failures? Sorry being slow here, just feels like I am missing something. I thought bounded are made |
|
If a send to an unbounded channel fails then the channel is either closed or the receiver has been dropped. In both cases that would mean the node has stopped. In the bounded case you'll notice the |
Ok, that mostly checks out with my understanding. But I don't think |
|
In short, yes you're right, but I'm going to ignore the catastrophic failure case here because the requests are very small, either scripts or transactions most of the time |
2 participants
The
UnboundedSenderoffers two advantages over bounding the number of requests a client can make. First it drops the need to maintain anasyncand sync version of the client methods -UnboundedSender::sendis synchronous. This is actually very convient forldk-node, where the client will have to implement a synchronous trait.Secondly there are some methods that are critical to succeed if the node is running. Adding a script must always work if the node is still online. Because it is unacceptable to miss some messages, there is basically two approaches: cache the failures and try again later, or use an unbounded channel. Since caching the failures will result in the exact same overhead as stored messages in a channel when the node is not ready to accept them yet, the unbounded channel is much easier to implement and reason about.