sockets - 使用套接字进行进程间通信有哪些限制？

Question

我正在创建一个 Firefox 扩展，允许使用标准 ML (SML) 作为 Firefox 中的客户端编程语言。其工作原理如下:

1. 该扩展启动 PolyML 进程(具有顶级交互式 shell 的 SML 编译器)。
2. 然后在扩展程序和 PolyML 进程之间建立套接字通信。
3. SML 代码从网页读取，并通过套接字发送到 PolyML 进程进行评估。
4. 然后，该代码可以使用我提供的库来处理 DOM。

以下是 DOM 库的实现方式:

1. 假设有人执行 SML 函数 DOM.getElementById
2. 此请求通过套接字转发到扩展程序，扩展程序在页面上执行 JavaScript 函数 getElementById 并通过套接字将结果发送回 PolyML 进程。

我的问题是，理论上，当涉及到套接字通信时，我应该期望在性能方面有哪些限制？

我做了一些非常近似的分析，似乎使用扩展程序和 PolyML 之间的接口(interface)，我大约可以发送 2500 条消息/秒，平均大小为 70 字节/消息。

为了更详细地说明这一点，假设我想使用 Canvas 元素在浏览器中绘制一些动画。如果我想达到 20fps，这意味着我需要在 0.05 秒内绘制每一帧，这意味着我每帧只能发送大约 125 条消息。这些消息对应于 JavaScript 函数调用。例如，下面的代码绘制了一条路径，并进行了 9 个 JavaScript 函数调用，这对应于套接字通信中的 9 条消息。

val _ = Canvas.beginPath context;
val _ = Canvas.setFillStyle context fillColor;
val _ = Canvas.setStrokeStyle context fillColor;
val _ = Canvas.setLineWidth context size;
val _ = Canvas.moveTo context posx posy;
val _ = Canvas.lineTo context posx_new posy_new;
val _ = Canvas.stroke context;
val _ = Canvas.arc context posx_new posy_new (size/2.0) 0.0 6.28 true;
val _ = Canvas.fill context;

显然，JavaScript 具有更好的性能，我想您可以在这 0.05 秒内进行数千(数百)次 Canvas/DOM 函数调用，以绘制框架。

所以，我想我的问题是，您是否有使用套接字通信进行快速消息交换的经验。我想知道 2500 条小消息/秒(在本例中，对应于 150 kbytes/秒)似乎正确，还是我可能做错了什么。

例如，有人怀疑 Firefox 中的套接字实现(特别是通过 JavaScript 接口(interface) https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIServerSocket 使用它)对于这种快速交互来说不是很好。例如，从套接字的读取是通过事件循环机制完成的。也就是说，我依靠 Firefox.. 通知我传入套接字消息的可用性，有时发送消息和接收消息之间存在很大(例如 250 毫秒)的延迟(尽管这似乎只在 Firefox 忙于执行操作时才会发生)其他事情，我对套接字通信的..理论上的..限制更感兴趣)

您看到任何想法、想法或缺陷吗？您认为使用其他 IPC 机制会更好吗？管道，从 C++ XPCOM 组件实现我的通信，而不是从 JavaScript、C 的外部函数接口(interface)(JavaScript 和 PolyML 都有)？

(该项目位于 https://assembla.com/wiki/show/polymlext 如果有人感兴趣的话)

Answer 1

可以调整 TCP 以获得更高的吞吐量或更快的响应时间。为了获得更高的吞吐量，您需要将套接字缓冲区设置为更大的值。为了使用较小的数据 block 获得良好的响应时间，您需要设置 TCP_NODELAY 套接字选项。如果经过微调，环回上的 TCP 应该与任何 IPC 机制相同。较新的 Windows 操作系统在环回适配器上进行了特殊优化，例如增加 MTU 大小等，以使其更快。