在同一台机器上运行的 Firefox 扩展和 C# 代码之间应该使用什么 IPC 方法？
我有一个关于如何在（新）Firefox 扩展和现有 C# 代码之间构建通信的问题。
Firefox 扩展将使用配置数据并生成其他数据，因此需要从某处获取配置数据并将其输出保存在某处。数据由现有 C# 代码生成/使用，因此我需要决定扩展应如何与 C# 代码交互。
一些相关因素：
- 它仅在 Windows 上运行，在相对受控的企业环境中。
- 我的机器上运行着一个用 C# 构建的 Windows 服务。
- 由于其他原因，将数据存储在本地数据存储（如 sqlite）中会很有用。
- 数据量很小，例如每隔几分钟就有 10kb 的未压缩 xml，而且不是很“健谈”。
- 数据交换在大部分情况下可以是异步的（如果不是完全的话）。
- 与所有项目一样，我的资源有限，因此想要一个相对简单的选择。
- 它不必具有超高性能，但不应增加大量开销。
- 我计划在 javascript 中构建扩展（尽管如果确实有必要的话可以相信）
我正在考虑的一些选项：
- 使用 XPCOM 到 .NET/COM 桥
- 使用 sqlite 数据库：扩展将读取并保存到其中。 C# 代码将在服务中运行，填充数据库，然后处理服务创建的数据。
- 使用 TCP 套接字在扩展和服务之间进行通信。让服务管理本地数据存储。
我对（1）的问题是我认为这会很棘手而且不那么容易。但我可能完全错了？我看到（2）的主要问题是 sqlite 的锁定：一次只有一个进程可以写入数据，因此会出现一些阻塞。但是，通常拥有一个本地数据存储会很好，因此如果性能影响不太大，那么这是一个有吸引力的选择。我不知道（3）是否特别容易或困难......或者对协议采取什么方法：自定义或http。
对这些想法或其他建议有何评论？
更新：我计划用 javascript 而不是 c++ 构建扩展
I have a question about how to structure communication between a (new) Firefox extension and existing C# code.
The firefox extension will use configuration data and will produce other data, so needs to get the config data from somewhere and save it's output somewhere. The data is produced/consumed by existing C# code, so I need to decide how the extension should interact with the C# code.
Some pertinent factors:
- It's only running on windows, in a relatively controlled corporate environment.
- I have a windows service running on the machine, built in C#.
- Storing the data in a local datastore (like sqlite) would be useful for other reasons.
- The volume of data is low, e.g. 10kb of uncompressed xml every few minutes, and isn't very 'chatty'.
- The data exchange can be asynchronous for the most part if not completely.
- As with all projects, I have limited resources so want an option that's relatively easy.
- It doesn't have to be ultra-high performance, but shouldn't add significant overhead.
- I'm planning on building the extension in javascript (although could be convinced otherwise if really necessary)
Some options I'm considering:
- use an XPCOM to .NET/COM bridge
- use a sqlite db: the extension would read from and save to it. The c# code would run in the service, populating the db and then processing data created by the service.
- use TCP sockets to communicate between the extension and the service. Let the service manage a local data store.
My problem with (1) is I think this will be tricky and not so easy. But I could be completely wrong? The main problem I see with (2) is the locking of sqlite: only a single process can write data at a time so there'd be some blocking. However, it would be nice generally to have a local datastore so this is an attractive option if the performance impact isn't too great. I don't know whether (3) would be particularly easy or hard ... or what approach to take on the protocol: something custom or http.
Any comments on these ideas or other suggestions?
UPDATE: I was planning on building the extension in javascript rather than c++
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我个人会使用 命名管道 来执行通信而不是套接字。它们的开销非常低，并且在 Windows 上非常可靠。
这在 C++ 和 C# 中非常容易使用。
I would personally used named pipes to do the communication instead of sockets. They're very low overhead, and very reliable on Windows.
This is very easy to use from C++ and from C#.
如果您需要任何类型的 RPC，请使用第一个。否则，您会发现自己编写了 RPC 语言、验证、构造/解构等，对于本地计算机上的某些东西来说有点过分了。
如果您有一个非常被动的插件，这是最好的选择。第三个组件完全解耦了两个进程，这对很多事情都很有用，包括如上所述的异步、测试、易于实现等。如果您想做大量消息传递，这可能是一个愚蠢的想法。< /p>
对于大多数事情来说，这可能是最好的选择。从通过互联网发送内容的角度来看，TCP/IP 很好，但您并不真正需要两个不同的 IP 地址，也不会因为设置网络服务器和可能的端口冲突而搞乱。管道或其他类似的串行通信模型更有意义。它解耦得很好，它可以完全异步（TCP/IP 是异步的，普通 HTTP 不是，管道也是），它非常容易测试（当然假设您不必编写任何协议），并且它不太关心代码库。这意味着明天，如果您的 C# 后端变成 Ruby 后端或 Python 后端，整个系统仍然“正常工作”。它也比 sqlite 更好，因为您不必担心使用插件打包整个库和数据库。
第三个选项的唯一缺点是（一）事情将是异步的，但应该是响应式和主动的，而 sqlite 不仅允许事情大部分是被动的，而且不会通过您关闭计算机一周来分阶段进行。 （二）对于 RPC 来说这也不奇怪，如果您想再次这样做，您最终会发明自己的协议或处理 SOAP 和 WSDL 等协议。
Use the first if you need any sort of RPC. Otherwise, you'll find yourself writing an RPC language, validations, construction/deconstruction, etc., just a little overboard for something on a local machine.
Best option if you have a very passive plugin. The third component entirely decouples the two processes, which is great for a lot of things, including as mentioned above, async, testing, ease of implementation, etc.. Probably a silly idea if you want to do a lot of message passing.
Probably the best option overall for most things. TCP/IP is nice from the standpoint of sending stuff across the internet, but you don't really want two different IP addresses or to mess around with setting up webservers and possible port conflicts. Pipes make more sense, or some other similar serial communication model. It decouples well, it can be entirely async (TCP/IP is async, normal HTTP is not, pipes are too), its very easy to test (assuming you don't have to write any of the protocol of course), and it couldn't care less about code base. Which means tomorrow, if your C# backend turns into say, a Ruby one, or a Python one, the entire thing still 'just works'. Its better than sqlite as well, since you don't have to worry about packaging an entire library and database with your plugin.
The only downsides to the third option, is (one) that things will be async but should be responsive and active, whereas sqlite allows things to not only be mostly passive, but it isn't phased by you shutting your computer down for a week. And (two) its not amazing for RPC either, if you want to do that again you end up inventing your own protocol or dealing with something like SOAP and WSDL.
好吧，如果您要使用 JavaScript，除了用 C++ 编写代理组件（这将允许您直接访问操作系统 API）之外，我看不到其他使用命名管道或其他依赖于系统的通信的方法。另一方面，如果您计划使用 TCP/UDP 进行 IPC，这对您来说会容易得多，因为 Firefox 提供了套接字服务，您可以从 JavaScript 组件轻松使用它们。
如果您担心阻塞，您可以使用异步套接字通信或线程服务来避免 Firefox GUI 的锁定，但请注意，许多对象只能从 Firefox 的主线程访问。
Well if you're going to use JavaScript I don't see another way to use named pipes or other system dependant communication other than writing proxy component in C++ which will allow you to access OS API directly. On the other hand if you plan to use TCP/UDP for IPC it will be much easier for you, because Firefox provides socket services that you can use easily from JavaScript component.
If blocking is your concern you can use asynchrony socket communication or threading services to avoid locking of Firefox's GUI, but be aware that many objects are accessible only from Firefox's main thread.
我选择的选项是#2：使用 sqlite 数据库。主要优点是：
显然，其中一些是依赖于场景的，所以我绝对不会说这是 FF extn 和 C# 服务之间通信的最佳通用选项。
更新：我们最初只使用了 sqlite 数据库，然后需要一些同步通信，因此后来从 C# windows 服务公开了一个由 FF 扩展调用的 http Web 服务。该 Web 服务现在由 FF 扩展和其他浏览器扩展使用。它是一项网络服务，这很好，因为它可以让不同语言的不同应用程序轻松使用。
The option I selected was #2: use a sqlite db. Main advantages being:
Clearly some of these are scenario-dependant, so I would definitely not say this is the best general-purpose option for communication between FF extn and C# service.
UPDATE: We used just a sqlite db initially, and then wanted some synchronous communication so later exposed an http web service from the C# windows service that is called by the FF extension. This web service is now consumed by both the FF extension and other browser extensions. It's nice that it's a web service as it makes it easy to consume by different apps in different languages.