社区
网络编程
帖子详情
传说 TCP是可靠的传送,信息不会丢失,可是……
何哀何欢
2005-08-18 02:33:42
为什么我的一个软件,每隔大概10秒就要给对方发送一些数据,使用TCP,数据丢失的很严重。为什么?如何才能保证数据不丢失?
...全文
403
19
打赏
收藏
传说 TCP是可靠的传送,信息不会丢失,可是……
为什么我的一个软件,每隔大概10秒就要给对方发送一些数据,使用TCP,数据丢失的很严重。为什么?如何才能保证数据不丢失?
复制链接
扫一扫
分享
转发到动态
举报
AI
作业
写回复
配置赞助广告
用AI写文章
19 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
何哀何欢
2005-08-24
打赏
举报
回复
我使用的是 CSocketFile::Flush() 不知这个函数的功能是不是就是立即发送?
zcy_beijing
2005-08-23
打赏
举报
回复
可以使没有send马上就发送数据,
写错了,是send后马上就发送数据
zcy_beijing
2005-08-23
打赏
举报
回复
楼主接收端处理有问题,TCP不象UDP是按照一个个包发送的,你接收端接收UDP的话是按照发送端发出的包一个一个收回来的,而TCP是面向流的,发送端的一个多个send调用可能才会发出一个包来,这是TCP为了提高效率设置的策略,这样在接收端收到的一个包可能是发送端发出的多个包,你必须要按照处理流的方式来处理你的数据,而不能简单认为你收到的一个包就对应你发送端发送的那个包。当然也可以在发送端做设置,可以使没有send马上就发送数据,而不等待。
CString strMsg;
BOOL bOption = TRUE;
int nRet = -1;
nRet = setsockopt(hCtrlSocket, IPPROTO_TCP, TCP_NODELAY, (char*)&bOption, sizeof(bOption));
if(nRet == SOCKET_ERROR)
{
Msg.Format("设置控制Socket的NODELAY出错,错误号为:%d",GetLastError());
ShowMsg(Msg);
}
Wolfe
2005-08-22
打赏
举报
回复
我的服务端客户端和客户端都用EventSelect模型,Server循环接收,也是超出中500万几率地接收不到Client的数据(虽然Client发送数据成功了),到最后也没有检查出Server的编码哪有问题。后来把Client改为阻塞模式,好像可以了。
我没有解决这个问题,失败!
chenzunshi3
2005-08-22
打赏
举报
回复
http://www.somade.com/是个很专业的技术社区,去那里找找吧,或许有你要的答案~
microyzy
2005-08-22
打赏
举报
回复
只要成功发送,不会丢的,丢的那是UDP,就不叫TCP了,可能是你程序自己的问题,再说你是不是在局域网里测试的?网络正常的话就算UDP也不会老丢包
Iris5
2005-08-22
打赏
举报
回复
to 楼主
你传送的数据包的长度可能太大了,所以会丢失!
杨桦LUOYANG
2005-08-21
打赏
举报
回复
我前段时间用TCP时,发现接收数据有“粘包”现象,即假设我发送的定长包是100字节,但接收时经常是100字节的N倍,需要处理,尤其快速发时。
我是8ms发送近100字节。(要求较精确时间,用多媒体定时器,所以不能用sleep)
jjiaming
2005-08-20
打赏
举报
回复
呵呵,今天晚上遇到了同样的问题,解决了.我只用了一个线程去给所有的客户端发数据,当数据发送相当频繁(比如说一次性给所有的客户端发送数据)时,数据丢失很严重,后来在循环里加了个Sleep(10),一切正常了
何哀何欢
2005-08-20
打赏
举报
回复
我用的是CSocket,发送和接收都 try 了。使用的是非阻塞模式,受到消息自会调用我的函数,然而有时候根本就不调用,说明没有受到消息。
如果是程序的问题,会出在哪?因为并不是所有消息都丢失,只是偶尔,但概率比我中500万高的多,这是为什么?程序出了什么问题的情况下可能会发生这种事情?
因为丢失情况随机发生,所以有没有什么好的调试方法?
gloomyfish
2005-08-20
打赏
举报
回复
看看你程序,tcp传输时候,接送端要循环接受,因为tcp会自动分片的
并不是说你组装多大的数据包,在接受端一次就可以接受到(可能也可以,如果网络好)
所以接受段的程序一定要check package 的 size.
masterz
2005-08-19
打赏
举报
回复
TCP网络连接会断,但不会丢失数据,如果包丢失了,TCP协议层会自动重发,你的应用程序不可能遇到丢包的情况,应该是你程序本身逻辑有错误。
yzkzero
2005-08-19
打赏
举报
回复
TCP协议本身是不会丢包的,网络丢包都由协议处理了,对于你而言,更本不可能出现丢包
所以,很明显,你的程序有问题
我曾经用一台FTTB的机器和一台无线通讯的电脑P2P通讯,网络状况很糟糕,速度很慢很慢,但绝对没有在我的程序中出现丢包!
nuaawenlin
2005-08-19
打赏
举报
回复
网络没有问题的话,tcp是不会丢数的.
很可能是你发送的时候出错了
检查每次发送的返回值
saliors
2005-08-18
打赏
举报
回复
楼主,tcp本身造成数据丢失的概率比你中500万的机会还要小得多,你现在的情况很明显是你自己程序的问题,在检查一下自己的程序吧。
nelsonc
2005-08-18
打赏
举报
回复
1. 可靠是相对的,是指协议不会主动丢弃数据。但如果网络等问题,包还是会丢的。
2. 如果你经常丢包,应该是程序问题了。
newbiestar
2005-08-18
打赏
举报
回复
信息不丢失是说如果监测到了丢失的话,协议会保证要求对方重新传输数据,并不是说书绝对不会丢失。
masterz
2005-08-18
打赏
举报
回复
多看看有关的代码,
bool RecvData(SOCKET sd,char* buf,int length)
{
int total = 0;
if(length<=0)
return true;
if(buf==NULL)
return false;
int readi = 1;
while(total<length&&readi>0)
{
readi = recv(sd,buf+total,length-total,0);
// if(readi==0)//the connection has been gracefully closed
// {
// return false;
// }
if (readi == SOCKET_ERROR)
{
return false;
}
else
if(readi>0)
total +=readi;
}
if(total==length)
return true;
else
return false;
}
int SendData(SOCKET sd,char* buf,int length)
{ //return 0: OK
//return -1: totalsent out ! = length
//return -2: SOCKET_ERROR
//return 1 : Socket was closed.
int totalsent=0;
int sentnum = 0;
while(totalsent<length)
{
sentnum=send(sd,buf+totalsent,length-totalsent,0);
if(sentnum>0)
totalsent +=sentnum;
else if (sentnum == SOCKET_ERROR)
{
return -2;
}
else
{
// Client closed connection before we could reply to
// all the data it sent, so bomb out early.
return 1;
}
}
if(totalsent == length)
return 0;
else
return -1;
}
gary137
2005-08-18
打赏
举报
回复
这不是传说,是真理!
数据丢了可以调试程序,看看是怎么回事?
java面经.pdf
JAVA面经,包含网络数据结构等内容 停止等待协议、连续 ARQ 协议、滑动窗口 一:停止等待协议 停止等待协议是
tcp
保证传输
可靠
的重要途径,”停止等待”就是指发送完一个 分组就停止发送,等待对方的确认,只有对方确认过,才发送下一个分组. 1:无差错情况:发送方发送分组,接收方在规定时间内收到,并且回复确认.发送 方再次发送…… 2:超时重传有以下三种情况: (1)分组
丢失
:发送方发送分组,接收方没有收到分组,那么接收方
不会
发出确认, 只要发送方过一段时间没有收到确认,就认为刚才的分组丢了,那么发送方就会 再次发送. (2):确认
丢失
:发送方发送成功,接收方接收成功,确认分组也被发送,但是分组
丢失
,那么到了等待时间,发送方没有收到确认,又会发送分组过去,此时接收方 前面已经收到了分组,那么此时接收方要做的事就是:丢弃分组,重新发送确认. (3):
传送
延迟:发送方发送成功,接收方接收成功,确认分组也被发送,没有
丢失
, 但是由于传输太慢,等到了发送方设置的时间,发送方又会重新发送分组,此时接 收方要做的事情:丢弃分组,重新发送确认. 发送方如果收到两个或者多个确认, 就停止发送,丢弃其他确认. 停
计算机网络学习26:
TCP
/UDP对比区别、
TCP
流量控制、拥塞控制、超时重传时间的选择、
可靠
传输的实现
UDP: User Datagram Protocol 用户数据报协议
TCP
: Transmission Control Protocol 传输控制协议 同时这里指的连接是指逻辑连接,而不是物理连接。
tcp
必须三次握手,才能建立
可靠
连接,也就是只支持一对一的通信。 应用层报文传下来之后或者交付上面,都是保留报文的边界。udp是面向报文的。
tcp
将应用进程发送下来的数据块仅仅看做是一连串的字节流。
tcp
并不知道字节流的含义,仅仅进行编号。 然后根据策略进行发送。 接收方接收到之后取出数据载荷缓.
TCP
的
可靠
传输
前言 面试官:你知道
TCP
吗? 李三:知道的,
TCP
是面向连接的
可靠
的…… 面试官:那你说说
TCP
它是怎么保证
可靠
的? 李三:what???我三次握手四次挥手贼溜,要不你问问这个? 面试官:没关系的,那今天就到这吧! 天天说
TCP
是
可靠
的
可靠
的,我们怎么能连它是怎么保证
可靠
的都不知道了。这个时候你就应该告诉面试官:所谓
可靠
传输,即要保证接收方从缓存区收到的字节流和发送方发出的字节流是一致的。一是需要建立连接来保证(这个我贼溜,要不你问问我这个?)。二是要有能检测到出数据是否出错并在出
【计算机网络】
TCP
可靠
传输的原理
计算机网络之
TCP
可靠
传输 一、
可靠
传输的工作原理 由于计算机网络是分层的,
TCP
发送的报文段是交给网络层的IP协议处理的。但是IP只能提供"最大努力服务",也就是说下层的网络提供的是不
可靠
传输,因此
TCP
必须采取一些措施保证
可靠
传输。 当传输过程中分组出现差错(检验和)时,应当让发送方重新
传送
分组;当网络状况不好或者接收方来不及接收分组时,应当适当降低发送速率(流量控制和拥塞控制)。 1.1 停止等待协议 简单的停止等待协议,即发送方每发送一个分组就等待确认,收到接收方的确认后在发送下一个分组。 当传
【计算机网络】
TCP
可靠
传输
TCP
可靠
传输
TCP
可靠
传输一、
TCP
可靠
传输概览二、校验和三、序列号和确认应答机制四、重传机制1⃣️超时重传2⃣️快速重传五、滑动窗口协议1⃣️累积确认2⃣️发送方的滑动窗口3⃣️接收方的滑动窗口六、流量控制七、拥塞控制1⃣️概念2⃣️
TCP
拥塞控制四种算法1.慢开始2.拥塞避免算法3.快重传和快恢复
TCP
可靠
传输 一、
TCP
可靠
传输概览
可靠
传输:接收方收到的字节流和发送方发出的字节流是完全一样的
TCP
保证
可靠
传输的机制有如下几种: 校验和Checksum 序列号和确认应答机制 重传机制 流量控制
网络编程
18,363
社区成员
64,187
社区内容
发帖
与我相关
我的任务
网络编程
VC/MFC 网络编程
复制链接
扫一扫
分享
社区描述
VC/MFC 网络编程
c++
c语言
开发语言
技术论坛(原bbs)
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章