Web版PACS开发纪要二:解决文件传输数据“丢失”问题

Web版PACS开发纪要二:DCM文件的网络传输

——解决文件传输数据“丢失”问题

目录

背景介绍

问题搜索

问题分析

问题解决


0背景介绍

该工程是上个月博文的延续。在利用“完成端口”完成了文件自动归档的基础上,本次需要利用socket套接字进行文件的远距离传输。虽然socket编程的参考书籍很多,但是在具体实现过程中还是遇到了各种各样的问题。下面继续记录一下工作中遇到的问题,一方面作为工作纪要,为后续工程的扩展做准备,另一方面作为自己学习的笔记,加深网络编程方面的知识。

首先说一下socket套接字传输文件部分的基本流程:首先利用上次完成的“文件夹实时监控”,将文件从分散的文件夹中归档到统一的目录下,默认为:e:\MedicalImages;然后利用socket套接字结合完成端口,将e:\MedicalImages文件夹下的文件传输到远端服务器。基本结构图如下:

Web版PACS开发纪要二:解决文件传输数据“丢失”问题_第1张图片

1问题搜索

Web版PACS开发纪要二:解决文件传输数据“丢失”问题_第2张图片

从图中可以看出,原始字节流(即源文件)比目标字节流(接收到的文件)多出了850字节。但是在调试过程中并未发现有send或recv函数发出错误,那么这“丢失”的850字节去哪里了呢?对此问题进行搜索

尝试一:send和recv函数是否是阻塞的?

send

客户端和服务端都通过send函数来向TCP连接的另一端发送数据

客户端用send向服务端发送请求;

服务端用send向客户端发送应答
recv 客户端和服务端都通过recv函数接收来自TCP连接另一端的数据

1.1简言之,阻塞就是send和recv必须完成其相应的任务才返回,将控制权交给自己编写的程序;非阻塞就是send和recv未等其任务完成就直接返回,将控制权交给调用者程序;

1.2阻塞时刻

send和recv函数的阻塞与accept函数的阻塞时刻略有不同,这是由于函数实现的功能以及TCP协议造成的。send函数的工作是将给定缓冲区(此缓冲区是程序中由程序员自己开辟的,存在于程序的堆或栈中)中的数据拷贝到TCP/IP协议栈的缓冲区(传输层开辟的接收/发送缓冲区,不同于程序员自己开辟的堆栈空间),在协议栈缓冲区未满时,阻塞和非阻塞的send函数效果相同都会直接返回,代表数据发送成功,其实此时数据依然存在于send端的TCP/IP协议栈的缓冲区中,并未真正发送出去;当协议栈缓冲区已满,阻塞和非阻塞的send函数就表现出了不同,阻塞send函数会将调用进程(线程)挂起,直到协议栈缓冲区中有足够的空间来存储send函数中指定的程序缓冲区数据,有时为了防止程序阻死会设置超时时间,当超过此时间阻塞send函数也会返回。非阻塞send函数发现协议栈缓冲区没有足够空间时,尽能力的拷贝,返回成功拷贝的大小;如缓存区可用空间为0,会立刻返回,并提示WSAEWOULDDBLOCK给程序员,告知“协议栈缓冲区已满,数据无法拷贝”——你自己想办法处理吧o(╯□╰)o”

【小结】:单步调试分项目,发现send和recv函数并未出现阻塞现象,也就是说在传送过程中TCP/IP协议栈的缓冲区空间充裕。那么为何会“丢失”数据呢?

参考博文:

http://blog.csdn.net/xiaofei0859/article/details/6037814    (Windows下情形)

http://blog.sina.com.cn/s/blog_4462f8560100tvu4.html      (Linux下的情形)

http://blog.sina.com.cn/s/blog_4d8498800100ddhb.html    (Linux下的情形)

http://www.360doc.com/content/12/0211/16/1317564_185797704.shtml

尝试二:send和recv是否一一对应?

send与recv从接收和发送角度来说是一一对应的,即有send就有recv,否则send就没有意义了(当然对发送的数据视而不见也是可以的);但是从函数调用次数角度考虑,send和recv并非是一一对应的,即send和recv函数的个数未必相同,两者可分别自行设置接收的字节长度,例如调用一次send函数发送100B数据,可以调用10次recv,每次接收10个字节。(那么怎样知道用10次recv来接收1次send发来的数据,而不是用9次或者8次呢?这就牵扯到TCP协议两端之间的信息交互,后面我会提到)

参考博文:

http://bbs.csdn.net/topics/60264256

尝试三:TCP/IP协议栈缓冲区

TCP协议利用滑动窗机制,来保证数据传输的可靠性和流控特性,TCP的窗口是一个16Bits的位字段,代表的窗口的字节容量,最大值为2^16-1=65535。TCP连接的两端分别维护各自的“发送窗口”和“接收窗口”(如下图所示),也就是说发送端和接收端分别独自拥有两个独立的缓冲区域——发送缓冲区和接收缓冲区。

Web版PACS开发纪要二:解决文件传输数据“丢失”问题_第3张图片

参考博文:

http://www.netis.com.cn/flows/2012/08/tcp-%E6%BB%91%E5%8A%A8%E7%AA%97%E5%8F%A3%E7%9A%84%E7%AE%80%E4%BB%8B/

2 问题分析

通过以上的资料搜索和分析,猜测“丢失”的字节可能是由于接收端程序编写的bug所导致的:原本以为阻塞模式下一次send调用对应一次recv,在接收端第一次调用recv时本意是 “只”接收客户端发送过来的用户和其影像文件的基本信息,信息格式约定为:用户ID&用户姓名&用户年龄&用户性别&用户出生年月&全路径名&文件名&文件大小

recv函数的原型为:

int recv(

 _In_   SOCKET s,

 _Out_  char *buf,

 _In_   int len,

 _In_   int flags

);

其中len指定的是buf缓冲区的大小;如果接收顺利,recv函数会返回其真实接收的字节长度。项目中我们固定buf缓冲区长度为1024,这远大于我们要接收的基本信息字节流的长度。单步调试进程序,发送端第一次send的基本信息为,长度为174;继续调试发现当程序中第一次recv的返回值不是基本信息长度174而是1024时,最终接收的文件会出现“丢失”字节现象,丢失的数目为850(=1024-174)。

分析:由于发送端多次send的结果,在接收端的接收缓冲区中已经存在了足够的数据,且长度大于为1024B,当接收端第一次调用recv时,系统并不知道基本信息字节流的具体长度,只能尽量拷贝足够多的字节到程序中的缓存buffer中,此处是1024B。在接收到基本信息后,接收端就想当然的调用ParseInformationString函数对基本信息进行解析,并未对此次recv接收的具体字节数进行判别,只简单的检验了是否成功,进而导致将接收的“基本信息”后的有效文件信息丢弃,并未写入到文件中。——到此终于找到了“丢失”的字节,原来所谓的“丢失”字节并未在TCP传输工程中丢失,而是由于接收端程序编写bug所导致,这也是文中一直对“丢失”添加引号的初衷。

3 问题解决

3.1 对recv接收的字节进行判别,如果长度等于1024,那么在解析基本信息完成后,将剩余字节写入到文件中。

Web版PACS开发纪要二:解决文件传输数据“丢失”问题_第4张图片

修改服务端代码,

              //2013-06-08修改:

              //对第一次recv的返回值进行判别,如果长度小于,那么说明此次接受内容只包含

              //需要的文件基本信息,如果长度等于,在解析完基本信息字符串后,将剩余的字

              //节单独拷贝出来,写入到文件中

              int rcv = recv(s, buffer, 1024,0);

 

              //1)计算用户基本信息字符串长度

              intBasicInfLen=7;

                                                 //     7——代表个&符号,这是我们能够确定的基本信息字符串必然包含的字符

              BasicInfLen= BasicInfLen+UserID.GetLength()+UserName.GetLength()+UserAge.GetLength()+UserBirth.GetLength()+

                                   UserSex.GetLength()+FileFullName.GetLength()+FileName.GetLength()+FileSizeStr.GetLength();

 

 

              if(rcv>BasicInfLen)

              {

                     file.Write(buffer+BasicInfLen,rcv-BasicInfLen);

                     iTemp+=rcv-BasicInfLen;

              }

 

具体分析如下:

客户端第一次send发送的信息如下:12345&TEST&2&男&2013-06-0814:06&e:\MedicalImages\12345\TEST\US\1.2.156.112601.1.4.8323329.2232.1368501262.762411.dcm&1.2.156.112601.1.4.8323329.2232.1368501262.762411.dcm&2361024

其长度为179.

服务端第一次接收recv的返回值rcv为1024.查看buffer内存如下:

Web版PACS开发纪要二:解决文件传输数据“丢失”问题_第5张图片

buffer+179内存结构如下:

Web版PACS开发纪要二:解决文件传输数据“丢失”问题_第6张图片

通过对比以上两个内存分布,可以看出首次接收到的1024字节中除去179字节的基本信息,剩余的恰巧是原本误认为“丢失”的DCM文件数据。至此证明方案一能够顺利解决问题。

3.2 设法同步send和recv,尽量做到一次send对应一次recv

由上文TCP/IP协议栈缓冲区结构图可知,阻塞socket下的send和recv在缓冲区已满或者缓冲区为空时,会发生阻塞(此处的阻塞指未释放控制权给程序员)。那么看能够巧妙的利用这一点来同步send和recv,达到在服务端接收并解析“基本信息”时,客户端不进入while(1);循环内开始图像的发送

原本我们只利用了TCP/IP协议两端的两个缓冲区,即服务端的接收缓冲区和客户端的发送缓冲区。客户端先向其发送缓冲区写入“基本信息”,然后逐次写入单位长度为1024B的文件信息块,利用TCP/IP协议传输到服务端的接收缓冲区,如下图中红线所示:

Web版PACS开发纪要二:解决文件传输数据“丢失”问题_第7张图片

此时由于两端的缓冲区不存在“无数据”和“数据已满”的情况,因此客户端的send和服务端的recv都不会出现阻塞现象。调用时能够直接获取足够的数据(项目中设定为1024B)。也正因为此才导致了原本的程序中不小心丢弃了部分数据。那么怎样才能尽量使客户端的send和服务端的recv同步,一一对应呢?这是就要利用其它两个没使用到的缓冲区:服务端的发送缓冲区和客户端的接收缓冲区。具体流程如下:

1)        在客户端发送完“基本信息”后,添加一次recv调用,由于此时客户端的“接收缓冲区”为空,那么recv函数会阻塞客户端程序;

2)        当服务端接收了“基本信息”后,对其进行解析后处理,待处理完毕后,添加一次send调用,发送确认消息给客户端,例如“READY_REC”字符串;

3)        客户端对recv函数的接收结果进行判别,看是否是“READY_REC”,如果是那么客户端进入while(1);开始文件有效数据的发送

4)        待客户端进入while(1);发送数据后,服务端也进入while(1);开始接收数据

至此利用客户端“接收缓冲区为空”来同步客户端与服务端的目的已经实现。示意图如下:

Web版PACS开发纪要二:解决文件传输数据“丢失”问题_第8张图片


Author:ZSSURE

Date   :2013-06-08

E-Mail [email protected]

你可能感兴趣的:(编程,socket,栈,文件传输)