#Fibers provides synchronous ‘put’ and ‘get’ operations on channels (inherited from Concurrent ML?).
This can be problematic if the sender doesn’t trust the receiver: the receiver can trivially DoS the sender. I wonder how Spritely comrades deal with this? @cwebber@tsyesika@dthompson
@civodul@tsyesika@dthompson It's worse than that: communicating sequential processes easily allows for malicious live-locking of processes. Request-response patterns are an easy example: send a process a message with a "reply" channel and the actor replying simply never does. But this can happen easily in any system where a process is switching between communicating between different channels: failure to deliver a message in one place can lead to cascading lock-ups. We avoid this particular issue by using an asynchronous inbox pattern and use promises as a primary pattern for communicating replies, etc. In other words, the actor model is safer than CSP.
However, per your original question, Goblins does not provide DoS protection by default. It can be layered. Solutions layering such a thing are also economic in nature (with all the downsides inherent). Backpressure can also lead to cooperative limiting.
But in general, per my understanding, this is not a solvable problem either. Whatever abstraction layer provides the rate limiting can also itself be DoS'ed. This is somewhat inherent to network architecture in general and I think someone in the ocap community was talking about several proofs.
You can't eliminate DoS issues entirely per my understanding, but you can provide mitigations.
@cwebber@dthompson@tsyesika Incidentally I realize that Cuirass is splattered with things like ‘put-message-with-timeout’. The problem in this context is that some of the actors cannot be trusted to reply in a timely fashion.
But if you start using timeout variants of ‘put’, you have to use timeout variants of ‘get’ as well to avoid lockups. So in the end, you probably end up with an all-asynchronous model where messages might have to be resent.
@cwebber@civodul@tsyesika@dthompson nit: what you're describing is still a regular deadlock, not a livelock. Livelocks involve processes still doing stuff instead of waiting, but just thrashing instead of actually making progress.
More seriously: the vat model has it's own footguns; blocking risks deadlocks, async mailboxes risk runaway memory use. "Adding backpressure" usually means deadlock risk again. You can also drop packets. No silver bullet, each system has its own risks & strengths.
The genode book (genode.org) has a really nice treatment about their approach: servers don't rely on clients. (it's a hierarchical partitioning of one machine's resources, not a p2p / market arrangement)
Comm primitives include: sync rpc with small/few args, async signals, shared memory.
Add comment