We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
比方说jmm之间:
js-process/worker-A
js-process/main
首先需要做好适配器,然后做连接策略。
The text was updated successfully, but these errors were encountered:
No branches or pull requests
TODO 提供一种更加通用的连接策略
我列举一种场景:
比方说我A模块在手机,B模块在PC,这时候A可能通过某个 https/wss 链接找到B了,二者现在通过https/wss这种协议进行链接。
然后二者尝试进行“更加紧密”的互联,在一些适配器的嗅探之下,它们发现两种链路:一种是通过WebRTC协议进行直连,一种是通过局域网UDP/QUIC互联。于是适配器进一步工作,UDP/QUIC链路最先成功建立连接。比原来的https/wss延迟很低速度更快,于是将这个链路的优先级提高,默认使用该链路。几秒后,WebRTC的握手也完成了,发现延迟并没有当前UDP/QUIC的更快,于是保留现在的链路选择。
比方说jmm之间:
js-process/worker-A
向js-process/main
这个线程发送一个uuid+MessagePortjs-process/main
询问uuid是否存在a. 发现存在,得到MessagePort,于是向 B-ipc-A 发送一些连接凭证,于是“更加紧密的互联”建立成功,切换使用新路径。
b. 如果不存在,那么向 B-ipc-A 发送失败讯息,于是保持原有的通讯路径
策略
首先需要做好适配器,然后做连接策略。
The text was updated successfully, but these errors were encountered: