多个端口传输少量数据，还是一个端口传输大量数据？
我一直在尝试使用名为 ROS 的系统（http://www.ros.org）工作。
ROS 中的网络节点之间发送有许多不同类型的数据。 您定义要在消息中发送的数据结构，ROS 将处理在仅发送该数据结构的两个节点之间打开特定端口。
因此，如果有 5 条不同的消息，就会有 5 个不同的端口。
与这种情况相反，我见过其他平台只是通过一个端口推送所有不同的消息。这意味着需要进行某种复用/解复用（通过接收端的某种消息解析来完成）。
我想知道的是......从性能角度来看哪个更好？
操作系统是否可以基于端口快速切换，以便像 ROS 这样的系统不需要做太多工作来找出消息中的内容并解释它？
或者
打开大量端口是否意味着大量较慢的内核调用，并且必须计算和转换消息类型的成本最终会超过在端口之间切换所花费的时间？
当扩展到高速率的大量数据和大量不同的消息类型时，将会有大量的端口。因此，我认为在扩展这些拓扑中的每一个时，性能将成为选择工作方式的一个重要因素。
我还应该指出，这些节点通常存在于一个小型网络上，或者大部分时间存在于一台机器上，其中网络被用作进程间通信的力量。因此传输时间只是整个系统时序中非常小的因素。
ROS 是一种机器人架构，每个传感器和执行器可能有一个节点，因此根据系统的复杂性，我们可能会讨论 20-30 个节点，在 10-100Hz 之间推送小型（100 字节左右）数据
I've been checking out using a system called ROS (http://www.ros.org) for some work.
There are lots of different types of data that get sent between network nodes in ROS.
You define a struct of data that you want to send in a message, and ROS will handle opening a specific port between the two nodes that will only send that struct of data.
So if there are 5 different messages, there will be 5 different ports.
As opposed to this scenario, I have seen other platforms that just push all the different messages across one port. This means that there needs to be a sort of multiplexing/demultiplexing (done by some sort of message parsing on the receivers end).
What I wonder is... which is better from a performance perspective?
Do operating systems switch based on ports quickly, so that a system like ROS doesn't have to do too much work to work out what is in the message and interpreting it?
OR
Is opening lots of ports going to mean lots of slower kernel calls, and the cost of having to work out and translate message types end up being more then the time spent switching between ports?
When this scales to a large amount of data at high rates and lots of different messages types there will be lots of ports. So I imagine that when scaling each of these topologies that performance will be a big factor in selecting the way to work.
I should also point out that these nodes usually exist on one small network, or most of the time on the one machine in which networking is used as a force of inter-process communication. So the transmission time is only a very small factor in the overall system timing.
ROS being an architecture for robots may have one node for every sensor and actuator, so depending on the complexity of your system we may be talking about 20-30 nodes pushing small-ish (100bytes or so) data between 10-100Hz
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这取决于。我不知道 ROS 的具体情况，但在网络中它归结为以下限制：
距离：光速很快，但超过一定距离后，它开始产生影响
协议开销：面向连接与无连接
在操作系统方面，维护空闲端口列表并不是这样的很大的开销 - 当然有成本但是一切都是相对的：如果您正在谈论具有长距离链接的分布式系统，那么很容易争论通过操作系统网络端口循环与管理通信质量相比，其关注度较低。
如果没有更具体的问题，我就到此为止。
It depends. I do not know the specifics of ROS but in networking it comes down to the following constraints:
Distance: speed of light is fast but over a distance it starts making a difference
Protocol Overhead: connection oriented vs. connection-less
On the OS side, maintaining a list of free ports isn't such much of an overhead - of course there is a cost to it but everything is relative: if you are talking about a distributed system with long distance links, then it is easy to argue that cycling through OS network ports ranks as lower concern compared to managing communication quality.
Without a more specific question, I'll stop here.
我没有这方面的任何数据，但与程序内的多路分解相比，多核系统可以更有效地处理多个端口，这似乎是合理的。
I don't have any data on this, but it seems plausible that multiple ports might be handled more efficiently by multi-core systems, as opposed to demultiplexing within the program.