双协议实现文件传输.docx

双协议实现文件传输.docx

《双协议实现文件传输.docx》由会员分享，可在线阅读，更多相关《双协议实现文件传输.docx（18页珍藏版）》请在冰点文库上搜索。

双协议实现文件传输

网络程序设计与实践

大作业实验报告

题目：

TCP/UDP双协议实现文件传输

学号：

xxxxxxxxxx

姓名：

xxx

指导教师：

xxx

学院：

xxxxxxxxxxxxxxxxxxx

学校：

xxxxxxxxxxxxx

一、实验目的

通过学习实践深入理解TCP/UDP等传输协议，掌握socket网络编程，理解它们的工作机制，并在实验中实现TCP/UDP双协议传输，通过自己的实现方式保证UDP的可靠传输，并使用进程预分配技术提高服务的性能。

二、实验要求

1.同时运行基于TCP与UDP的双协议

2.基于UDP协议的可靠传输

3.应用进程预分配技术

4.不上传，只下载

三、实验平台与语言

LinuxUbuntu9.04，C语言

四、实验设计思路

1.进程预分配设计

创建一个进程的时间比较长，如果在接收到客户端请求之后，创建一个子进程来处理，这会影响响应客户机的速度，为解决这个问题，采用一种称为“预创建（perfork）”的技术。

服务器事先创建一定数目的子进程，对于TCP连接，每个子进程分别调用函数accept（）从倾听套接字完成连接队列中接收已建立的客户机连接。

对于UDP情况，由于要实现可靠传输，客户机要向服务器发送的数据报确认信息，这就会使其他进程认为这是一个新的连接，所以在这里我采用信号量机制，使得在一段时间内，只有一个进程在处理UDP连接，只有这个UDP连接处理完成后，其他进程才可以接收UDP连接并进行处理。

也就是说，采用进程预分配技术后，可以实现TCP并发服务，UDP循环服务。

使用预创建技术的服务器如图1。

图1预创建子进程方式

服务器预先创建N个子进程，部分子进程正在处理客户机请求，部分子进程正在等待客户机请求。

这种服务器的优点是响应客户机的速度比较快，节省创建子进程的时间。

但缺点是服务器预先估计所需创建的子进程数目。

如果数目太少，那么多余的客户机讲等待，不能及时得到服务，而太多又会浪费系统资源。

为了解决上面的问题，服务器父进程可以动态的调整子进程数目，当空闲子进程数目小于下限时，父进程创建一些新的子进程；当空闲子进程大于上限时，父进程终止一些子进程。

父进程需要两条消息来管理子进程：

子进程接收一个连接和结束一个连接。

当父进程接收的前一种消息时，将检查空闲子进程数目是否小于下限；当父进程接收都后一种消息时，将检查空闲子进程是否大于上限。

为了获得这两种消息，父进程和每个子进程建立一个管道。

当子进程接收到一条连接后，向这个管道中发送一字节消息，内容为1；当子进程处理完一个连接之后，向这个管道发送一个字节消息，内容为0.服务器的示意图如图2所示。

图2动态更改子进程个数

为了管理子进程，定义一个结构child_queue，记录活动子进程数目，空闲子进程数目和子进程信息队列。

子进程信息队列记录了每个子进程的信息：

子进程的进程号，与父进程通信的管道和子进程的状态。

子进程状态可能是等待客户机请求（CS_WAITING）或处理客户机请求（CS_PROCESSING）。

structchild_queue{//结构:

用于管理子进程

intchld_no;//活动子进程数目

intchld_avail;//空闲子进程数目

structchild_info{//子进程信息

intpid;//子进程进程号

intpipefd;//与子进程通信的管道

intstate;//子进程状态

}ci[CHILD_NUM_MAX];//子进程信息数组

};

服务器一直循环动态管理子进程数目，知道有SIGINT信号出现（CTRL+C），才Kill所以子进程，退出循环，结束。

进程预分配的流程图如图3所示。

图3进程预分配流程图

2.子进程处理连接及双协议实现

当一个子进程被创建后，它循环等待客户机连接请求，当客户机连接请求到达后，它判断是TCP连接，还是UDP连接。

如果是TCP连接，子进程调用tcpfile（）函数处理连接请求，在tcpfile（）处理请求过程中，调用accept（）函数从倾听套接字完成连接队列中接收已建立的连接，如果接收成功则通过管道通知父进程开始处理连接，父进程把它的状态置为CS_PROCESSING（处理客户机请求），然后判断空闲子进程数目是否小于下限，如果小于，则创建一定数目新的子进程。

当连接处理完成后，子进程通过管道通知父进程连接处理完成，父进程把它的状态置为CS_WAITING，然后判断空闲子进程数目是否超过上限，如果超过，Kill一定数目的空闲子进程。

而处理此次连接的子进程处理完成后继续等待新的连接。

如果是UDP连接子进程先判断是否有其他进程正在调用udpfile（）函数处理UDP连接，如果有，则说明这个连接有可能是客户端发送给服务器的数据报确认信息，那么子进程继续等待新的连接。

如果没有其他子进程正在调用udpfile（）函数处理udp连接，则对信号量执行P操作，然后调用udpfile处理本次UDP连接，处理完成后对信号量执行V操作，以便其他子进程调用udpfile（）函数处理新的UDP连接。

在调用udpfile（）处理UDP连接时，同样需要通过管道和父进程通信，以便父进程动态管理子进程数目。

子进程处理连接流程图如图4所示。

图4子进程处理连接

图5基于TCP协议的通信方式

3.基于TCP协议文件传输的设计

TCP，UDP属于传输层协议，无法直接应用于传输文件。

所以无论基于TCP还是基于UDP都需要单独开发各自独立的应用层协议。

由于TCP协议提供可靠地传输，所以我们就不用考虑可靠性。

图5是客户端和服务器端基因TCP协议的通信方式。

图6基于TCP的服务器端流程图

客户端首先请求连接，当收到连接确认后，发送要下载的文件名，如果文件在服务器端存在，服务器给客户端发文件存在确认信息，如果文件不存在，服务器给客户端发文件不存在信息。

如果文件不存在，客户端提示文件不存在，重新输入文件名并发送。

如果文件存在，服务器发送文件数据，客户端接收服务器发送的文件数据，一直循环直到文件传输完毕。

然后客户端关闭套接字，端口连接，而服务器端子进程，处理完本次连接后继续等待新的连接到来。

图6是基于TCP的服务器端流程图，图7是客户端流程图。

由于服务器采用进程预分配，TCP套接字和倾听套接字都是在父进程中创建的，在图6服务器端流程图中没有体现出来。

图7基于TCP的客户端流程图

4.基于UDP协议文件传输的设计

由于UDP协议不提供可靠传输，所以在这里我们需实现可靠传输机制。

在这里应用的是停等超时机制，图8显示了基于UDP协议的客户端和服务器端的通信方式。

可靠传输机制可以描述如下：

在文件传输过程中，服务器端先给文件数据报进行0或1编号（规定编号从0开始），然后发送数据报，计时等待接收客户端数据报编号ACK，如果服务器端未在规定时间内收到客户端编号ACK，则重新发送本次数据报，如果服务器端在规定时间内接到客户端的编号ACK，则判断编号ACK和本次发送的是否相同，如果相同，则对下一个数据报进行1或0编号并发送；如果客户端的编号ACK与本次发送的不同，则说明客户端没有收到本次数据报，重新发送，计时等待客户端数据报编号ACK。

如果重新发送次数超过10次都没有收到客户端编号ACK，则认为客户端断开了连接，服务器子进程返回继续等待新的连接。

正常情况到文件发送完毕，然后服务器子进程给客户端发送一个文件发送完毕信息。

不等待客户确认，然后返回继续等待新的连接。

基于UDP协议服务器端流程图如图9所示。

图8基于UDP的客户端和服务器端通信方式

而基于UDP的客户端，一开始发送请求的文件名字并得到存在确认后，就开始等待服务器端的数据报（由于规定数据报编号从0开始，第一个接收到的数据报编号应该为0，然后以后依次为1.0.1.0……），接收到一个数据报后，判断是否是希望得到的编号的数据报，如果是，则给服务器端发送本次得到的数据报编号ACK，如果不是就给服务器端发送上次的数据报编号ACK。

图10是基于UDP协议的客户端流程图。

图9基于UDP协议的服务器端流程图

图10基于UDP协议的客户端流程图

五、实验结果与分析

为了方便观察，每次TCP或UDP连接，在服务器端都显示连接类型，IP和端口，以及下载的文件。

1.基于TCP协议的文件传输

图11服务器运行

图12客户端连接

图13服务器端显示TCP连接

图14客户端输入文件名data并下载

图15服务器端TCP连接显示下载文件data

2.基于UDP协议的文件传输

图16UDP客户端运行并输入文件名

图17UDP客户端连接并下载文件

图18服务器端显示UDP连接及下载的文件

从图18可以看出服务器实现了TCP和UDP双协议。

当有TCP连接时调用tcpfile（）函数进行处理，当有UDP连接时调用udpfile（）函数进行处理。

3.进程预分配

图19有5个TCP客户端同时连接

图20服务器端预分配的5个子进程分别对每个连接处理

4.UDP超时重传

图21UDP客户端下载文件

图22服务器超时重传

六、实验总结

由于时间及经验的关系，设计上还有很多不足之处，但是基本功能都予以实现。

本次实验积累了很多经验，熟悉了线程和socket编程，获益匪浅。

实验的核心是“基于UDP协议的可靠传输”，关键是实现一种可靠传输的机制，至于传输的效率反而是其次。

只要实现了前者，后者只是优化的问题。

但实验之初往往本末倒置，希图设计一种高效的传输协议而对可靠的传输机制考虑不足。

最后，感谢xxx老师精彩的讲解和耐心的指导，在此向他致敬！