How does MessagePort work? How Are Renderers Kept Track of ?

[Hao Liu]

Hi,

I'm trying to understand how render-to-render IPC work. Specifically, this MessagePort. 

I would imagine, for render-to-render IPC to work, one renderer should be aware of the other as frames are added/removed and consequently renderer processes can be created and destroyed. But I didn't find relevant docs as to how this works.

Also, there's a lifecycle management issue I guess. 

Can anyone point me to where I can learn more about this?

Thanks!

[Reilly Grant]

Under the hood a MessagePort is a Mojo pipe, and Mojo supports arbitrary process-to-process connections and cross-process tracking of message pipe lifecycles: https://chromium.googlesource.com/chromium/src/+/master/mojo/README.md

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/366dadcd-00a4-4df2-adb3-63e3bba5e22cn%40chromium.org.

[Hao Liu]

Thanks Reilly.

I thank I didn't phrase my question properly.

I have a problem.

For a frame, I want to send some data to all its ancestor frames hosted in other render processes.  

One way is render-browser-render.

The other is render-to-render IPC.

But I'm trying to understand how oner render process can keep track of the render processes hosting its ancestors. 

I suppose when a frame is added and hosted in another render process, it need to inform its ancestors and its descendants. This seems to be very complicated if not unmanageable. 

I'm wondering if if there is a simple way to do this?

On Thursday, February 16, 2023 at 1:07:59 PM UTC-5 Reilly Grant wrote:

Under the hood a MessagePort is a Mojo pipe, and Mojo supports arbitrary process-to-process connections and cross-process tracking of message pipe lifecycles: https://chromium.googlesource.com/chromium/src/+/master/mojo/README.md

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

On Wed, Feb 15, 2023 at 12:08 PM Hao Liu <hao...@chromium.org> wrote:

Hi,

I'm trying to understand how render-to-render IPC work. Specifically, this MessagePort. 

I would imagine, for render-to-render IPC to work, one renderer should be aware of the other as frames are added/removed and consequently renderer processes can be created and destroyed. But I didn't find relevant docs as to how this works.

Also, there's a lifecycle management issue I guess. 

Can anyone point me to where I can learn more about this?

Thanks!

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

[Reilly Grant]

It is indeed quite complicated but the data structures which keep track of this information already exist. For example, if you are in Blink and have a Frame object you can call the Parent(), FirstChild() and other such methods to get objects representing its ancestors and descendants.

Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Marijn Kruisselbrink]

And see for example RemoteFrame::ForwardPostMessage for how window.postMessage calls are forwarded from one renderer process to another process. Although those do go through the browser process I believe. In the case of a MessagePort between different renderer processes, presumably the site would have send one of the MessagePorts for a channel over some other IPC (i.e. window.postMessage, via the browser process) to get one port in each process. Once that setup is done, further messages can go directly from renderer to renderer. And you can do the same with arbitrary mojo interfaces; have a process send one end of a mojo pipe to another renderer process via the browser process, and then messages can be passed over that pipe directly between renderer processes.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAEmk%3DMbpggq1oW2jjYV85VGmFJKu2qDDpChOHQdUFUdzSQrunA%40mail.gmail.com.

[Charlie Reis]

I think we generally discourage renderer-to-renderer IPC messages, don't we?  Or has that changed?  Usually it's important for the browser process to interpose on the messages to prevent a compromised renderer from directly attacking another renderer, or validating parts of the message (like the source and target origins for postMessage).

For context, some of the classes involved in these cases are described in https://www.chromium.org/developers/design-documents/oop-iframes/, though there may be parts of that doc which are a bit out of date.  There's also methods like WebContentsImpl::ExecutePageBroadcastMethod for tasks that need to be sent to all the renderers involved in a page.

Charlie

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CA%2BOSsVaPNP-XKXK4LEyHhhHQ6kkybQf0Qi%3DMi5Bh%2Bm3PabyxUw%40mail.gmail.com.

[Hao Liu]

Thanks all!

I also replied in another thread.

I was leaning toward the render-browser-render model as it seems to be as pattern we use while render-to-render requires some sort of keeping track of frames added/removed. 

but the idea of render-to-render saves 1 ipc so I wanted to find out its feasibility. 

I think I now have more clues and I'll just go with the render-browser-render model as people suggested. 

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/366dadcd-00a4-4df2-adb3-63e3bba5e22cn%40chromium.org.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAEmk%3DMbpggq1oW2jjYV85VGmFJKu2qDDpChOHQdUFUdzSQrunA%40mail.gmail.com.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

[guest271314]

I am not sure about using Chromium source code to achieve the task. It is certainly possible to connect different arbitrary tabs and windows using MessagePort and other means at the front end to send JSON, or streams. See https://github.com/guest271314/sw-transfer-stream, https://github.com/guest271314/offscreen-webrtc,. I filed this FUGU some time ago for the ability to connect arbitrary Web pages using TransferableStreams https://bugs.chromium.org/p/chromium/issues/detail?id=1214621 as an optional substitute for IPC that Native Messaging uses.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/366dadcd-00a4-4df2-adb3-63e3bba5e22cn%40chromium.org.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAEmk%3DMbpggq1oW2jjYV85VGmFJKu2qDDpChOHQdUFUdzSQrunA%40mail.gmail.com.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.