TCP 编程问题

learntolinux

原帖由 吃烤鱼 于 2009-5-23 14:12 发表



tcp会重新发送，直到送达

好像不是吧 ， 重试的时间是有限制的 好像是4~10分钟吧

learntolinux

原帖由 benjiam 于 2009-5-23 13:48 发表
红蓝军问题。 最后一次确认永远没办法确认是否成功送达

解决方案
1 应用层要自己设计协议来确认消息发送成功。
2 1问1答 1确认就可以了

我也是这么想的，这也是我最不想看到的结果 ！！！

binbin_as

TCP握手和其他机制应该可以自己解决的吧，可以让接收端在完整收到数据后，发送一个小的响应包塞
              -------正在看TCP，不知道对不

milowind

具体有没有发送成功是传输层层（TCP协议层）关心的问题

ideawu

有个概念楼主可能理解错了. TCP和TCP socket并不是同一个东西. TCP socket是应用程序接口, 是对TCP的包装, 是用户(调用send发送字段流的程序)和底层TCP的中间层. TCP尝试保证数据确实正确地传到对端, 如果无法成功, 本端也能知道. 只是, 套接口层(socket)没有提供这样的接口, 不是TCP不提供.

[ 本帖最后由 ideawu 于 2009-5-24 22:10 编辑 ]

ideawu

应用程序
    |
套接口系统调用(read, write)
    |    进程
------系统调用-------
    |    内核
套接口系统调用实现
    |  函数调用
套接口层函数
/  |  \
-------------
TCP UDP ...

benjiam

其实 还是有很多细节没有仔细研究过

a<===> b 建立连接 3步握手完成

非阻塞模式
a send 100 字节

如果b 没有返回ack 包， 也不返回rst . a 机器的反应。 是返回100 还是阻塞？

返回是等待b 返回ack， 还是压入内核栈以后就返回。

urapple

不对，阻塞方式tcp send如果返回成功，就是成功了，失败，基本上就是网络出问题了。别管什么发送缓冲还是应用程序。
tcp本身的send就有recv过程，只有收到确认，才会继续发送下面的数据，否则如果发送缓冲满，send就阻塞住了，不会返回，你的上层程序也会一直等待，直到发送缓冲腾出空间。只不过应用层没有看到。如果把这点否定，就没法再往下开发了。
非阻塞方式tcp send返回成功与否，可真是只是说有没有拷贝到发送缓冲里，所以，一般情况，网络程序刚开始都要设置发送缓冲和接收缓冲，把他们搞大，在搞大 ^_^
非阻塞的发送失败，就要判断下，到底是什么错误了，可能是正常错误，所以非阻塞发送一般都需要循环发送（在发送失败的时候）。
不过，无论阻塞，非阻塞，只要是tcp，他的send都有recv过程，这点毋庸置疑。
这是小弟以往开发网络程序的一点经验。要是不对，还是以tcp协议为准。呵呵。

learntolinux

原帖由 benjiam 于 2009-5-24 22:46 发表
其实 还是有很多细节没有仔细研究过

a b 建立连接 3步握手完成

非阻塞模式
a send 100 字节

如果b 没有返回ack 包， 也不返回rst . a 机器的反应。 是返回100 还是阻塞？

返回是等待b 返回ack， 还 ...

我看了一些资料，我理解的是 ： 无论阻塞还是非阻塞，a send 100 字节， 压入栈就返回（资料上说拷贝到TCP缓存），这时 100自己有可能还在本端或是发到了对端但是对端还没有返回ack。如不对，请指正！  好像和楼上的观点部分相冲突，呵呵！！

[ 本帖最后由 learntolinux 于 2009-5-25 09:14 编辑 ]

bobozhang

原帖由 urapple 于 2009-5-25 08:30 发表
不对，阻塞方式tcp send如果返回成功，就是成功了，失败，基本上就是网络出问题了。别管什么发送缓冲还是应用程序。
tcp本身的send就有recv过程，只有收到确认，才会继续发送下面的数据，否则如果发送缓冲满， ...

我觉得有误，不管阻塞还是非阻塞，send或write成功都不代表对方的协议栈已经接收到了我们数据，也不代表我们的数据一定从网口发出去了。