SCTP 与多宿主作为 TCP 的直接替代品
SCTP 具有本机多宿主支持，如果我理解正确的话，如果主接口出现故障，它会自动通过辅助 NIC 重新路由您的数据包。我通过编写自定义路由守护程序来使用 TCP 复制此功能，以便在我的主 NIC 出现故障时修改路由表。我想尝试使用 SCTP 代替。
在 Steven 的 Unix Network Planning V1 第三版第 288 页中，它说：
对于这个例子，我们使用 一对多风格的服务器。我们做 这一选择有一个重要原因。 第 5 章中的例子可以是 修改为通过
SCTP运行 小改动：修改socket函数调用来指定IPPROTO_SCTP而不是IPPROTO_TCP作为第三个参数。 然而，简单地进行此更改， 不会利用任何SCTP提供的附加功能 多宿主除外。
现在我已经尝试过这一点，但结果相当糟糕。
我在 Ubuntu 9.04 上运行，安装了 libsctp1、libsctp-dev 和 lksctp-tools 软件包。我已使用 lksctp-tools 验证 SCTP 工作正常。
我采用了 UNP 示例代码 并按照上面所示的 ~/unpv13e/tcpcliserv/ 进行了修改tcpserv04.c 和 ~/unpv13e/select/tcpcli02.c 程序。
这是一个简单的回显服务器/客户端对。服务器运行时表面上正在监听，但客户端退出时表示连接被拒绝。由于 netstat 不支持 SCTP，我使用了 lsof -n | grep tcpserv 向我展示了：
tcpserv04 6208 alice 3u sock 0,4 33889 can't identify protocol
除了 tcpserv04 有某种打开的套接字之外，这似乎并没有告诉我太多信息。
我已经在 perl 中重写并测试了原始的 TCP 客户端，因此我将其切换到 sctp 并且能够连接，尽管在 stdin 上传输文件并没有完全工作（在接收回声返回时挂起大约 2/3） 。
UNP 似乎暗示将 TCP 应用程序移植到 SCTP 以利用多宿主是微不足道的，但基于这个简单的尝试，事实似乎并非如此。
任何人都可以为我指点一个好的教程，或者就将 TCP 应用程序移植到一对一风格的 SCTP 以利用多宿主时需要注意的任何问题提供好的建议吗？
SCTP has native multi-homing support which if I understand it correctly will automatically reroute your packets over a secondary NIC if the primary interface goes down. I duplicated this functionality with TCP by writing a custom routing deamon to modify the routing tables if my primary NIC goes down. I would like to try using SCTP instead.
In Steven's Unix Network Programming V1 3rd Edition on page 288 it says:
For this example, we use a
one-to-many-style server. We make
this choice for one important reason.
The examples in Chapter 5 can be
modified to run overSCTPwith one
minor change: modify thesocket
function call to specifyIPPROTO_SCTPinstead ofIPPROTO_TCPas the third argument.
Simply making this change, however,
would not take advantage of any of the
additional features provided bySCTP
except multi-homing.
Now I've tried this with fairly poor results.
I'm running on Ubuntu 9.04 with the libsctp1, libsctp-dev, and lksctp-tools packages installed. I've verified with lksctp-tools that SCTP is working properly.
I took the UNP example code and modified as indicated above the ~/unpv13e/tcpcliserv/tcpserv04.c and ~/unpv13e/select/tcpcli02.c programs.
This is a simple echo server / client pair. The server runs apparently listening, but the client exits saying the connection was refused. Since netstat doesn't support SCTP I used lsof -n | grep tcpserv which showed me:
tcpserv04 6208 alice 3u sock 0,4 33889 can't identify protocol
This doesn't seem to tell me much other than tcpserv04 has some kind of socket open.
I had already rewrote and tested the original TCP client in perl, so I switched it to sctp and was able to connect although piping a file on stdin didn't completely work ( hung about 2/3's of the way through receiving the echo's back ).
It seems like UNP is implying that porting TCP applications to SCTP to take advantage of multi-homing is trivial, yet based this simple attempt that doesn't really seem to be the case.
Can anyone point me to a good tutorial or give good advice on any gotcha's to watch out for when porting TCP apps to one-to-one-style SCTP to take advantage of multi-homing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
tcpcli02尝试连接到端口 7，而tcpserv04侦听端口 9877（SERV_PORT的默认值）。更改它们以匹配之后，它对我有用。一般来说，对 SCTP 的支持非常差。除非您控制要连接的主机之间的整个网络基础设施，否则我不会指望它可靠地工作。
正如 UNP 中提到的，移植应用程序本身应该相当轻松。
tcpcli02tries to connect to port 7, whiletcpserv04listens on port 9877 (the default value forSERV_PORT). After changing those to match, it works for me.Support for SCTP generally is very bad. Unless you control the entire network infrastructure between the hosts you are trying to connect, I would not count on it to work reliably.
Porting the applications itself should be fairly hassle-free, as mentioned in UNP.