SCTP 适合点对点应用程序吗？
我正在考虑对用 C 编写的 p2p 应用程序使用 SCTP 而不是 TCP。我应该这样做吗？ SCTP 的速度与 TCP 的速度相比如何？
编辑： 我发现 SCTP 可以通过 UDP 建立隧道唯一的问题是隧道 SCTP 不能与非隧道 SCTP 互操作。
I am considering using SCTP instead of TCP for a p2p app written in C. Should I do it? Also how does the speed of SCTP compare to the speed of TCP?
EDIT:
I found that SCTP can be tunneled over UDP with the only problem being tunneled SCTP is not interoperable with untunneled SCTP.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您是否考虑过您的目标系统是否都预装了 SCTP，或者您的应用程序是否需要包含 SCTP 本身？ 根据我的经验，我不希望所有系统都安装 SCTP，如果是 Windows，我也不希望它们安装 SCTP。
如果您在应用程序本身中包含 SCTP，那么与使用预安装的 TCP 相比，传入内核外的消息数量将增加一倍以上，这将影响性能。
您是否考虑过希望从 SCTP 中获得什么好处？ 您提到了容错，但要使其与 SCTP 配合使用，需要应用程序具有多个以太网端口和 IP 地址。 这可能出现在您的应用程序上吗？
尽管我非常喜欢 SCTP（！），但我会认真考虑坚持使用 TCP，除非您确定需要 SCTP 或者除非您控制部署应用程序的主机。
问候
Have you considered whether your target systems will all have SCTP pre-installed on them or whether your application will need to include SCTP itself? In my experience I would not expect all systems to have SCTP installed on them, and I would expect them not to if it were Windows.
If you include SCTP in the application itself then that will more than double the number of messages being passed into an out of the Kernel which will impact performance when compared with using the pre installed TCP.
Have you considered what benefits you want from SCTP? You mentioned fault tolerance but for this to work with SCTP it requires the application to have multiple ethernet ports and and IP addresses. Is this likely on your app?
As much as I love SCTP (!) I would seriously consider sticking with TCP unless you are sure SCTP is needed or unless you control the hosts your app is deployed on.
Regards
如果是局域网的话，一定要使用。
但请注意，如果您计划在开放互联网上使用它，许多消费级防火墙不够灵活，无法允许无法识别的 IP 协议通过。
If it's for a local area network, sure go for it.
Note however that if you plan to use it on the open internet many consumer grade firewalls aren't flexible enough to permit unrecognised IP protocols through them.
它对你有什么帮助？
您是 P2P，因此每个对等点都必须至少有一个对每个其他对等点开放的套接字。
如果你有一个打开的套接字，那么你就可以对其进行任何你需要做的事情。 如果您采用每个文件一个套接字的方法，并且在两个给定对等点之间同时传输多个文件，那么 SCTP 将为每个文件节省一个套接字。 然而，在任何规模的普通 P2P 网络上，您几乎永远不会在两个对等点之间同时传输多个文件。
只需一个套接字并拥有自己的小协议； 发送带有标头的数据包，标头指示内容类型，例如命令或文件的一部分 - 如果是，则指示哪个文件以及哪个字节范围。
当然，您会为此付出一点开销，而如果您有一个用于命令的套接字并且每个文件都有一个套接字，那么您的效率会更高。 为每个对等方节省一个套接字（假设一次下载一个）是否值得使用 SCTP 花费时间/麻烦/复杂？
How does it help you?
You're P2P, so every peer must have at least one socket open to every other peer.
If you've got a socket open, then you can do everything you need to do over that. If you've taken the approach of one socket per file and you have multiple files being tranferred concurrently between two given peers, then SCTP will save you one socket per file. However, on a normal P2P network of any size, you will almost never have multiple files being transferred concurrently between two peers.
Just have one socket and have your own little protocol; send a packet with a header, the header indicates content type, e.g. a command, or part a file - and if so, which file, and which byte range.
Of course, you get a little overhead for that, whereas if you have one socket for commands and one per file, you're more efficient. Is saving one socket per peer (assuming one download at a time) worth the time/hassle/complexity of using SCTP?