feat(dot/parachain): manage communication between different parachain subsystems (i.e., build overseer)

[kishansagathiya]

Issue summary

lib/parachain has a bunch of subsystems that need to run in parallel and there are more of these subsystems that will get added.

Many of them need to communicate with each other by say calling some function or fetching some data.

It would not be a nice design to connect two parachain subsystems directly, because

• It would require us to manage a lot of links/connections for each subsystems
• we might need to add extra logic to make these communication non-blocking

It would be nicer to have say a separate subsystem to manage these communications (equivalent to polkadot's overseer subsystem). The idea is that

• each subsystem will only communicate with overseer subsystem only.
• each subsystem will send their request to a overseer and continue with rest of its task without waiting for a reply. overseer will send a reply whenever it is ready.

Because overseer would mandate each subsystem to perform some common task, we could create an interface say SubSystem that could have tasks like

• receive requests for overseer
• process them and send a response.

Feel free to do these task as separate function or as part of the same function based on your best judgement.

I will update this issue as I go and make my understanding more clear.

Sub Issues

• [x] #3495

Other information and links

• Polkadot's implementation of overseer https://github.com/paritytech/polkadot/blob/153543b0c8c582e73f520e5c08cbe33bddfb5f69/node/overseer/src/lib.rs
• Explanation in node implementer's guide https://paritytech.github.io/polkadot/book/node/overseer.html

[kishansagathiya]

@kanishkatn @edwardmack @axaysagathiya

I would love to know if you have any alternate or additional design ideas for this.

[kanishkatn]

I'm taking a look at the overseer and I have some concerns.

In the Rust implementation, it supports three usecases

• SendMessage Sends a message to the overseer and waits for the response
• Feed Sends a message to the overseer and doesn't wait for any response
• SendUnBoundedMessage A separate channel without any message limits. This ensures that the messages from the subsystem will always reach the overseer without wait.

In the current implementation, I've noticed that there is only one channel between the overseer and a subsystem. This may lead to channels getting blocked and lead to hard to debug issues.

I suggest not to keep one single channel to send a response message from overseer to the subsystems and add a way for the subsystem to specify the receiver channel along with the message to the overseer.

I'm not sure if this has already been discussed; I'm open to suggestions as well!

[kishansagathiya]

I suggest not to keep one single channel to send a response message from overseer to the subsystems and add a way for the subsystem to specify the receiver channel along with the message to the overseer.

This has been discussed. We have plans for adding a response channel in messages itself. If you look at this line in a recent PR, that exactly what happens. https://github.com/ChainSafe/gossamer/pull/3535/files#diff-1798eac991bfd7b07d6a7ff83ec171d8c42e31207d805115c9f8f86a95df33c3R205

[kanishkatn]

This has been discussed. We have plans for adding a response channel in messages itself. If you look at this line in a recent PR, that exactly what happens. https://github.com/ChainSafe/gossamer/pull/3535/files#diff-1798eac991bfd7b07d6a7ff83ec171d8c42e31207d805115c9f8f86a95df33c3R205

Glad y'all are aware and it is being addressed!

I also see a need for these

• A secondary channel for fast processing; I don't have a good understanding of it yet, but a food for thought https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/node/core/dispute-coordinator/src/initialized.rs#L1042C52-L1042C52
• A Sender interface instead of using the channels directly for better error handling.