IPC Improvements

[wusyong]

While @JonasKruckenberg working on tauri-bindgen, I feel like we should have a place gather the summary on our current status. I'll try to use this discussion as experiement.

Tauri's invoke and command feature have a main bottleneck which is parameters and return values are serialized around strings. This is the restriction from webview libraries on different platforms. I wrote down the summary in tauri-apps/wry#767. In that issue, I also brought up some possible improvements we could make in the near future.

For now, if you really want to maximize the performance, I think you can register a custom protocol by register_uri_scheme_protocol. Read headers from the request as parameters and return what javascript in the browser wants. Note that on Linux, this requires webkit2gtk 2.36 which is not supported by ubuntu 18.04. Part of reasons we can't offer certain API around it in v1.

[Beanow]

Types of bottleneck, use-cases

For reference, testing, reproducing. If you have / know of a particular use-case and which type of bottleneck you're running up against, do share here. Some ideas:

Data volume / bandwidth

• Backend generated images?

Throughput / large number of messages

• @jbolda's color picker example?

Latency

• Terminal emulator

[JonasKruckenberg]

Note that on Linux, this requires webkit2gtk 2.36 which is not supported by ubuntu 18.04. Part of reason we can offer certain API around it in v1.

A small note here: I strongly believe that addressing the IPC performance bottleneck is too important to wait for wider adoption on Linux, and, additionally, WebView2 might soon support zero-copy messaging, something we would be stupid not to take advantage of. This means going forward, Tauri will have to have a number of strategies, falling back to the current slow implementation on systems that are still stuck on old webkitgtk versions. The current feature matrix would then look a bit like this:

• Linux: ipc.postMessage or custom protocol as appropriate
• macOS: custom protocol
• Window: custom protocol or sharedBuffer (the zero copy binary messaging)

We should keep this in mind when designing the new IPC API, and abstract these strategies in a way where we can phase out the use of ipc.postMessage gradually as adoption on Linux grows, importantly without introducing a breaking change.

PS: The story on linux might even be more complicated than this, as support for the new IPC features not only requires Headers, but the request Body too (which afaik has not received any work yet right?)
So depending on how important we deem IPC performance on Linux, it might be worth implementing an version "0.5" of the custom protocol solution that doesn't support bi-directional streaming as the Body fix would probably take over a year to be meaningfully available on Linux distros

[M1cha]

@JonasKruckenberg to cite from your tauri-bindgen readme:

We're planning a big rework of the IPC bridge in the coming months and tauri-bindgen has been designed with some of the early design-work in mind.

• Who's "we"?
• Were does that rework happen? I can't find any public information on this(issues, discussions, ...)
• In case it's non-public: Can we change that? Where can I follow the current progress?

[jthoward64]

@JonasKruckenberg to cite from your tauri-bindgen readme:

We're planning a big rework of the IPC bridge in the coming months and tauri-bindgen has been designed with some of the early design-work in mind.

• Who's "we"?
• Were does that rework happen? I can't find any public information on this(issues, discussions, ...)
• In case it's non-public: Can we change that? Where can I follow the current progress?

I feel like 'the coming months' have come and gone, any info on this?

[FabianLars]

the new ipc is part of v2 which is in alpha for a while now. tauri-bindgen was not (yet?) part of that change.

[jthoward64]

Gotcha, thanks!

[samkearney]

For now, if you really want to maximize the performance, I think you can register a custom protocol by register_uri_scheme_protocol. Read headers from the request as parameters and return what javascript in the browser wants.

Just a curiosity about this. Documentation about these custom protocol handlers seems to be centered around an HTTP-style single-request-to-single-response pattern. What if I want to do something like streaming raw binary data continuously from my backend to a webview, for an extended time (i.e. the lifetime of the app), in the style of WebSockets? Is there any workaround you can think of for this in Tauri v2?

Right now I am looking at using the raw Windows SharedBuffer APIs directly, but I am hoping that there is an easier solution than that because it looks daunting 😄 (and is not cross-platform)

[JonasKruckenberg]

Yes! With tauri v2 we added an async counterpart to the register_uri_scheme system that allows you to call a callback as many times as you want with additional data. This lets you do streaming long-lived connections

[samkearney]

Hi @JonasKruckenberg,

Thank you for the response! I'm assuming you're referring to register_asynchronous_uri_scheme_protocol(). Maybe I am missing something, but I had already looked at this API, and it seems like it only allows responding once to a request via the UriSchemeResponder. The method respond() says "Resolves the request with the given response", and it takes a complete HTTP response structure and consumes self. So, to me it seems like the only difference is that it just allows you to respond once, later, instead of once, right now. I am not immediately seeing an API that will let me do something like, for example, chunked transfer encoding which enables using the streams API on the client side, or something similar. Could you please advise?

[samkearney]

I found this which seems to indicate that this streaming feature is not supported by WebView2 on Windows. So at least on the Windows side, it seems very unlikely that this pattern is supported by custom protocol APIs in Tauri.