双协议实现文件传输.docx
《双协议实现文件传输.docx》由会员分享,可在线阅读,更多相关《双协议实现文件传输.docx(18页珍藏版)》请在冰豆网上搜索。
![双协议实现文件传输.docx](https://file1.bdocx.com/fileroot1/2023-4/28/5401211b-9230-4d2e-b346-f53a55183170/5401211b-9230-4d2e-b346-f53a551831701.gif)
双协议实现文件传输
网络程序设计与实践
大作业实验报告
题目:
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老师精彩的讲解和耐心的指导,在此向他致敬!