A communication protocol defines the requests and responses that independent components exchange. In an actor-based simulation, it hides the underlying environment and becomes the contract that lets each actor interact without knowing whether it runs against a real subsystem or a simulator. section 8.1.1
The protocol separates domain logic from orchestration. Spaceship parts can run as independent lightweight threads while the simulator controls their lifetimes and interactions invisibly. The same control scripts can therefore describe both real subsystems and simulated actors. section 8.1.1
A request–response protocol must address several practical concerns:
- Define the messages exchanged by the requester and responder. section 8.1.3
- Coordinate concurrent access so a request receives the corresponding result. section 8.3
- Avoid protocols whose broad request and response types permit invalid pairings, such as receiving a reversed string after requesting a square. section 8.1.3
- Move to message queues or STM when a large MVar-based model becomes difficult to express or maintain. section 8.3
MVar Request–Response
A pipe pairs an MVar for requests with an MVar for responses. The requester puts a value into the request MVar and waits for a response; a worker repeatedly takes the request, applies a function, and puts the result back. A FizzBuzz processor and generator use this arrangement to exchange results across two threads. section 8.1.3
Figure 8.2 Real environment and virtual environment
Compare the real environment with the virtual environment that the protocol allows actors to treat identically. section 8.1.1
Figure 8.5 The MVar Request–Response pattern flow
Trace the flow from request submission through worker processing to the returned response. section 8.1.3
