Need advice on using XState to implement a network protocol

[HerbCaudill]

I'm using XState to implement a peer-to-peer authentication protocol. Events are all network messages received from the peer.

Most of the time, things work as expected - something like this:

I have an intermittent bug that results from the timing of message delivery. For example, suppose Alice's HELLO message to Bob is delayed in transit, and when her CLAIM message arrives, Bob is still in the Initializing state, which doesn't respond to the CLAIM message. By the time Bob enters the awaiting identity claim state, it's too late - the CLAIM message has been discarded, so the process hangs.

This will also fail if messages are delivered in a different order than they were sent - for example, if CLAIM is delivered before HELLO.

I'm thinking that I'll probably need to solve this outside of XState, with a message delivery layer that queues up messages as they come in, orders them correctly, and only delivers them when the state machine is ready. I'll probably need a timeout/retry mechanism as well.

I would imagine that others have come across this kind of issue when using XState to implement network protocols - are there any good examples out there? And are there any mechanisms within XState for dealing with these kinds of issues?

[davidkpiano]

Here's a defer/recall strategy that you can use: #1305 (comment)

[Andarist]

I have only learned about the term and what it does in the abstract but in Erlang there is a mechanism called "selective receive" that would come in handy here. It just basically allows for priority matching of incoming messages and putting unhandled ones to the temporary space - so basically what you have showcased in that linked comment. There are probably a bunch of different use cases that some kind of prioritizing could solve - Akka also supports priorities from what I recall.

I was thinking about this a few times and I was thinking that maybe we could standardize a mailbox property that could be configured with custom ones that would match a particular use case. Just food for thought.

[davidkpiano]

I was thinking that maybe we could standardize a mailbox property that could be configured with custom ones that would match a particular use case. Just food for thought.

This is a good idea for XActor, which is meant to be just the actor-model implementation (no state machines), and then we can (hopefully) bring the XActor implementation into XState v5.

[davidkpiano]

Link to Erlang's "selective receive": https://www.tutorialspoint.com/erlang/erlang_concurrency.htm#:~:text=Selective%20Receive,of%20the%20Selective%20receive%20statement.

[kiliman]

is it just me, or is "selective receive" inherently dangerous?

As soon as a message has been matched, then all messages that have been put into the save queue are reentered into the mailbox in the order in which they arrived at the process. If a timer was set, it is cleared.

For example, let's say you send a DELETE message where current state doesn't match, so it's put into the save queue. You then send another message that eventually switches to a state that accepts the DELETE message. The machine now processes the DELETE message. To me that doesn't sound right. I would expect the machine to reject any messages that the current state doesn't accept.

[Andarist]

I would expect the machine to reject any messages that the current state doesn't accept.

And this is what happens now and what will always happen by default.

There are situations when you want to preserve out-of-order messages and process them after switching to a new state - like the one described here by @HerbCaudill. I believe this is a very common use case in Erlang as it's very focused on network messaging. Even when an event gets put back to the main mailbox from the save queue you have the power to dismiss it this time - it all depends on your logic. I'm not an expert though - I would expect that when using this feature you need to be thoughtful about cases like yours to prevent them. It's like with anything else - it has some cons, it has some pros. Always pick the right tool for the job :) Also - in Erlang you also don't have to use this pattern all over the place, it's just an option.