※ 引述《Killercat (杀人猫™)》之铭言： : ※ 引述《LaPass (LaPass)》之铭言： : 不要用单纯的raw socket, 稍微看一下TCP的listen/accept是怎麽实做的 : 去改一下TCP的实作方法 : Server端来说 : a TCP开一个socket port : b TCP等着这个socket port收讯息(listening) : c TCP收到Client讯息(accept), 开一个新的socket port并且告诉client该port : d TCP断开该client连结 继续listening, 新的socket port喂client资料 : Client端来说(分别对应上面的abcd) : a Client开一个socket port : b Client连结某个listening的TCP socket port : c 收到Server告诉你的接下来要跟谁接头的port number : d 从该port number取得服务 : [略] 这一篇乍看之下有些不对劲，特别是 raw socket 这说法与作者在推文里的回应。 不过作者想要表达的重点是：如果你无法在单一的串流里同时妥善地处理属於 command 与 data 的部分，可以考虑(类 FTP)把 command 与 data 分开在不同 的串流里去传输。 的确这样子对於使用 socket 串流来传输 command or data 的程式部分来说， 在实作上会比较单纯。但是实作这种服务的 server 的复杂度提高很多，server 必须同时管理多个 server socket(one for command, others for data)，以及 维护各个非 command 用途的 server socket 所管理的 socket 应在什麽时刻 输出什麽 data 种种的细节。(走 HTTP protocol 都没这麽复杂，概念上 HTTP 的 command 与 data 是在同一个串流上) 注：除非你把部分 burden 转移到 client 去，client 要收 data 时要自己开 server socket 等 server site 去连接。在实务上这个要求能避免就避免，因为 这等於要求 client site 要有 global IP，不然就是要求 client 要能够妥善 去处理 NAT 的设定。 要自定 Protocol 比较简单的方式是去规范传输数据的 format 与 framing，让 双方对於任一次所传输的区块中的那个子部分是哪种意义(包括 interpret 方式) 有相同的看法/做法；为了简化单次传输所需要做的事情，而把概念上属於一个 操作的事情拆成多个子操作 flow 来完成，我个人是觉得不妥，考虑到完整性与 效率，要实作好这样的 server 是很不容易的。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 218.173.235.231 ※ 编辑: sbrhsieh 来自: 218.173.235.231 (11/19 14:29)