write socket时的一个疑问

思一克

你这是好方法吗？
不是。速度会慢许多许多。

"那么平时编网络程序时应该如何来解决这种问题呢? 我现在也只是在应用层自己制定了一种协议, 即在write之后就调用read, 通过read的返回值来判断. 不知道各位还有没有什么其它的好方法?
"

cugb_cat

原帖由 思一克 于 2007-12-22 21:50 发表
你这是好方法吗？
不是。速度会慢许多许多。

"那么平时编网络程序时应该如何来解决这种问题呢? 我现在也只是在应用层自己制定了一种协议, 即在write之后就调用read, 通过read的返回值来判断. 不知道各位还有 ...

版主给说一个好方法嘛，呵呵。

scutan

原帖由 xhl 于 2007-12-22 20:35 发表


我没怎么看明白你的 问题， 给你点建议， 也许不是你的问题的 答案。

windows linux 还有部分 unix kernel已经提供了 tcp keepalive的 能力，

你只需要用 setsockopt 设置己个 arg就可以了  keepali ...

谢谢, 我的意思其实就是说如果我在向另一台机器write的时候, 那台机器突然断网了, 所以此时的发送机收不到任何可以提示的信息, 如EOF, RST包之类的, 如果在我write之后我再调用 read 或者是 write的话, 则可以发现这个问题, 但是如果就不再调用 read , write之类的了, 我发送机就根本不能确认我之前那个write是否能够成功到达. 所以为了保证可靠性, 我一般都要再一次的read或者是write以确定一下.
我就是想请教一下, 大家在遇到这种问题的时候是如何处理的.

scutan

原帖由 思一克 于 2007-12-22 21:50 发表
你这是好方法吗？
不是。速度会慢许多许多。

"那么平时编网络程序时应该如何来解决这种问题呢? 我现在也只是在应用层自己制定了一种协议, 即在write之后就调用read, 通过read的返回值来判断. 不知道各位还有 ...

请版主指教, 我就是把我的想法说出来, 然后再希望得到大家更多的指导. 谢谢!

converse

我最近在看lighttpd的代码,也是这样做的.

scutan

嗯. 谢谢, 这种方法确实是要比我说的那种效率高.

>>直到最后发完,或出错误,或TIMEOUT.
当不断地发送完毕之后也应该会有一个recv之类的操作吧, 以确定是否所有的send都已经成功. 因为如果没有这一步仍然无法确定是否所有的都已成功.

>>2)发送方一般知道一个箱子发车后最长多久一定可以收到上海的收到确认电话.比如一天.如果3天还没有,北京也可以确定路上出问题了.
这一步, 也应该是使用recv来完成的吧. send完了之后没有办法知道是否成功.

总之, 我的看法是, 不管是一次send一次recv还是多次send, 之后总得有一个recv来实现这个可靠的通知.
谢谢指教.

思一克

应用层有协议确然。

但不应该是每个write之后确认， 而是多个（几十，几百，数千个）以后确认。
比如你有10M的一个邮件要发，DATA后发送端就不断发了，接受端收到结束标志后，发一个OK类似的话告诉发送端。发送端10M发完后要收一下。

原帖由 scutan 于 2007-12-23 14:38 发表
嗯. 谢谢, 这种方法确实是要比我说的那种效率高.

>>直到最后发完,或出错误,或TIMEOUT.
当不断地发送完毕之后也应该会有一个recv之类的操作吧, 以确定是否所有的send都已经成功. 因为如果没有这一步仍然无法 ...

scutan

原帖由 思一克 于 2007-12-23 15:02 发表
应用层有协议确然。

但不应该是每个write之后确认， 而是多个（几十，几百，数千个）以后确认。
比如你有10M的一个邮件要发，DATA后发送端就不断发了，接受端收到结束标志后，发一个OK类似的话告诉发送端。 ...

明白了, 谢谢!

思一克

不用。

原帖由 scutan 于 2007-12-23 15:14 发表


明白了, 谢谢!

scutan

谢谢前面各位的关注, 不过分只能给一位朋友, 以后有机会再补上.