解决C# Socket发送数据大小问题
TCP/IP是可靠性传输协议,它能保证数据能按顺序的方式到达目的地.看到以上描述在写TCP/IP应用的时候似乎就可以放心了,只要程序不出意外就数据输传就是正确.但最近在做一个文件传输工作的时候确得到的结果并不是这样,发现网络环境和一次发送数据大会影响整个输传结果.以下是这两晚的测试情况
测试内容描述:
每个文件块信息包大概是120k左右
采用异步5连接输传,双方的Socket.SendBufferSize和Socket.ReceiveBufferSize都设置为64K
测试服务器分别有:
局域网:ServerA
在美国机房:ServerB 延时高,Ping有时会超时
测试client一台,通过ADSL上网.
以下是Client从Sever下载文件的情况:
服务器8K SendBuffer,客户端是8K ReceiveBuffer
从ServerA下载文件,分别下载多个文件几M到几百M不等,下载后文件正确.
从ServerB下载文件,分别下载多个文件,几M或更小的文件有部分正确,大文件基本都是错误.两端记录的发送的字节数和接收的字节相等,符合文件大小,程序也没有跟踪到数据接收异常导致的协议分解错误.
服务器4K SendBuffer,客户端8K ReceiveBuffer
从ServerA下载文件,分别下载多个文件几M到几百M不等,下载后文件正确.
从ServerB下载文件,分别下载多个文件,文件的正确率比较高,不过还是大文件相对错误比较多.当开启迅雷下载后情况就开始变坏,大部分接收到的文件都出问题,两端记录的发送的字节数和接收的字节相等,符合文件大小,程序也没有跟踪到数据接收异常导致的协议分解错误
服务器2K SendBuffer,客户端8K ReceiveBuffer
从ServerA下载文件,分别下载多个文件几M到几百M不等,下载后文件正确.
从ServerB下载文件,分别下载多个文件,下载结果没有发现错误文件.当开启迅雷下载后还是有个别文件错误,两端记录的发送的字节数和接收的字节相等,符合文件大小,程序也没有跟踪到数据接收异常导致的协议分解错误
服务器1K SendBuffer,客户端8K ReceiveBuffer
从ServerA下载文件,分别下载多个文件几M到几百M不等,下载后文件正确.
从ServerB下载文件,分别下载多个文件,下载结果没有发现错误文件.当开启迅雷下载后没有发现文件错误.
测试文件发送到Server和下载的情况基本差不多,这说明了在网络不好的情况处理发送大数据包似首容易产生错误,但看TCP/IP协议讲解这情况似乎不存在,因为当一个发送数据超过某个值的时候,TCP会划分块进行传输并保证其顺序.但网络不好的情况测试结果接收的数据有错误,但处理的数据大小是正确的,也并没影响整个协议的分解.由于对CP/IP协议、低层和路由处理的不了解,暂没找到具体原因。。。不排除程序存在还没发现的错误,打算给发送的文件数据加上校验再测试一下看情况
补充一下
以上测试只修改了一个属性
TcpUtils.SendBufferLength = 1K,2K,4K,8K
但只有1K的测试结果奇怪地没出现文件错误,其了几中均出现仅仅是对ServerB,对ServerA来说没有出现,2K,4K也只是开启迅雷的时候错误情况多.
原文链接:http://www.cnblogs.com/smark/archive/2012/02/02/2335442.html
【编辑推荐】
相关文章
- 达梦、GBase、星瑞格,你用了哪个?
- 使用快照策略和镜像备份数据
- 风向标:数据库技术趋势解读
- 微店MySQL自动化运维体系的构建之路
- DBA呢?我的数据库又双叒叕连不上了!
- 比大数据还要可怕的是什么?没有数据!
- 15年老司机的DPM数据库性能分析产品研发之路
- 在Oracle专家眼中,MySQL sys Schema是怎样一种存在?
- 数据也会说谎:常见的数据造假三种形态!
- 巧用利器Powershell,让数据库自动化运维事半功倍
- 记一次区域DB突发变慢的SQL优化博弈
- 为什么我们用的系统这么烂?谁的锅?
- 罕见故障!数据库对象编号达到最大值,必须重新建库!
- 炉石传说罕见数据库事故!丢失30%数据,疑似误操作?
- 未来:数据是商品,你就是猎物
- 从小型网站到超大规模网站的MySQL参考架构
- Flink及Storm、Spark主流流框架比较,到底谁会更胜一筹?
- Seaborn 常用的 10 种数据分析图表
- 简化数据湖可为组织节省时间和资源
- 贾扬清团队攻克大数据计算性能瓶颈,阿里云连续两年打破大数据最难纪录