文件传输协议范例(3篇)

文件传输协议范文

关键词：客户端；服务器；文件传输协议；数据传输

中图分类号：TP393文献标识码：A文章编号：1009-3044（2017）07-0043-02

互联网在全球范围内的发展和普及，方便更快捷的共享网络资源，由此可见，开发Linux平台下的MiniFTP客户端具有重要的现实意义

1FTP总体分析

文件传输协议（FileTransferProtocol，英文简写FTP）是支持网络中文件传输的标准协议。它属于网络协议组的应用层。FTP服务使用的是C/S模式，即FTP服务器和客户端的通信实际是点对点的通信。

FTP服务模型如图1。

注意：在整个FTP过程中数据连接是双向的，而且数据连接无需在整个时间存在。

在FTP过程中，各模块之间互相交互，共同实现FTP服务。它们在此期间充当的角色如下：

PI：协议解释器。用户、服务器分别关联着任务user-PI、server-PI。

服务器-PI：服务器协议解释器从端口L处“监听”，确认有无user-PI连接，形成控制通信连接。基于user-PI获得FTP指令，随后给予回应，对server-DTP进行控制。

用户-PI：用户协议解释器对其U端口至server-FTP过程进行管理，若此过程属于文件传输的一个组成，可以初始化FTP指令，接着控制user-DTP。

DTP：数据传输过程，与管理数据相连，存在主动、被动两种形式。

服务器-DTP；数据传输过程，通常表现为“主动”状态，形成具备“监听”端口的数据连接。考虑到传输与存储设置参数问题，应当由PI经指令传输数据。DTP处于“被动”状态时，接收信息，相比直接相连数据端口，作用更加理想。

用户-DTP：主要负责server-FTP过程的数据连接，传输时监控数据端口。若服务器间进行数据传输，那么user-DTP随之结束。

服务器-FTP过程：可以与user-FTP过程，或相关服务器协作，实现文件传输功能的过程，包含大量处理构建的集合，其核心部分是协议解释器（PI）与数据传输过程（DTP）。

用户-FTP过程；可以和1个及以上server-FTP过程协作，实现文件传输功能的集合。主要由但部分构成，分别是协议解释器、数据传输过程、用户界面。而对于用户界面，能够依靠本地语言呈现回应的对话。

FTP指令；FTP指令分为三类，访问控制指令，传输参数指令，FTP服务指令。访问控制指令指定访问控制标识符。各个数据传输参数均存在缺省值，只有通过缺省值的控制，才可以通过相关指令明确传输参数。FTP服务指令表示用户要求的文件传输与系统。

FTP回应：可以使数据传输请求、过程始终一致，也可以是用户进程直观确认服务器运行情况。

每个FTP回应均由3个数字以及相关文本组成。前者可以对下一步即将出现的状态进行确认，而后者能够主要呈现给真实用户。

回应码首个数字包含以下5个值。

1yz确认预备应答。及请求的操作处于初始化状态，后续指令处理前接受其他应答。

2yz确认完成回应。该操作执行完毕，能够重新进行请求。

3yz确认中间回应。获得质量，而操作遭到中止，此时可以获取其他信息。

4yz暂拒完成回应。指令尚未接受，操作也未执行，然而错误条件呈现出暂时状态，能够接着请求。

5yz拒绝完成应答。指令尚未接受，操作也未执行。

以下代表第二个数字相关的功能编码。

x0z语法――主要确认语法中的错误并给予标记。指令输入正常，但不具湎嘤功能；无用、没有执行的指令。

x1z信息――主要确认请求信息，包含状态、帮助等信息。

x2z连接――主要确认控制、数据连接状态。

x3z认证与帐户――主要确认登录操作与账户程序。

x4z保存。

x5z文件系统――主要确认服务器文件系统状态，和请求的传输、部分文件系统操作存在联系。

第三个数字在前者的基础上对功能类别进行了更全面的描述。

在整个FTP过程模型中，用户-PI首先按照Telnet协议控制连接。用户初始化期间，能够借助用户-PI生成有效的FTP指令，同时依靠控制连接发送至服务器过程。标准回应同样可以借此由服务器-PI传输至用户-PI。FTP指令能够给数据连接、文件系统操作（存储，下载等等）设置参数（数据端口、结构等）。用户-DTP必须通过特定数据端口进行“监听”，服务器原始数据连接，依靠合适的参数确保传输过程始终同步。在此强调一点，数据端口、初始化FTP指令需要的主机可以存在区别，然而，用户-FTP过程应当通过特定数据端口进行“监听”。同时，数据连接不仅包括传输，而且包含接收。

2FTP总体设计思路

基于上面对FTP协议模型的分析，设计程序流程、用户交互接口以及控制连接和数据连接的管理。

2.1用户FTP流程

整个程序流程图如图2。

2.2用户接口设计

用户接口主要是用来实现用户和程序的通信。本系统向用户提供的命令接口有：

2.3用户-Pl设计

在系统中，用户-PI的作用是将用户输入的指令进行解析，然后将指令翻译成标准的FTP指令通过控制连接发送给FTP服务器。在本系统中通过定义一个cmd结构体数组cmd_tab[]，列出了用户PI所能解析的命令。它将用户的命令cmd_name转化为cmd_handler处理函数。控制连接访问在本系统中是通过访问创建的socket套接字ftp_sock_fd来实现。

2.4用户-DTP设计

在系统中，用户-DTP负责在客户端和服务器进行数据传输，系统中通过函数initconn（）和dataconn（）创建数据连接，数据连接的套接字用变量data表示。而数据传输则通过函数ftp_send_and_resv（）对套接字data读写来实现。

文件传输协议范文篇2

流式传输的功能是对连续的声音和图像信息进行打包处理，然后传到网站服务器，供用户进行下载，其中用户可在多媒体文件下载结束前，进行播放多媒体文件。其主要原理是开始下载的部分内容会被缓冲在某一存储区域中，如果网络传输速度跟不上客户机播放时所需要的转换速度，此时音视频播放器会自动的将存储区域中的缓存部分文件进行调配，保证用户播放多媒体文件的连续性，也可保持良好的播放效果。流媒体不仅改进了互联网只表现静态文字和图片的缺点，还可以展示直观、灵活的视频课堂，以及可对大量的并发点播请求作做式处理，这一优势可在大规模点播环境中得到很好的应用。本系统中建立了流媒体教学视频播放系统。其中，流媒体资源配置系统主要由流媒体服务器、媒体编码压缩工具包、客户端播放器、传输网和流媒体传输协议这六部分构成。其中媒体编码压缩工具包主要是在创建、捕捉和编辑多媒体数据时进行启用，以获取流媒体数据格式；客户端播放器，主要是对流媒体文件中的相关内容进行播放和浏览，以实现学习的目的；传输协议包括RTP、RSVP等。采用流媒体技术之后，系统达到了以下目的：

1）数据压缩比高。流媒体所利用的压缩方式，将流信息添加到文件，这一处理不但可以提高数据压缩比，还可以把动画、音/视频等多媒体文件打包成若干个压缩包，以便客户端能够实时连续地接收来自服务器的压缩包。

2）可节省客户端的缓存及硬盘空间。流媒体技术的应用，用户可以在多媒体文件下载的同时，在客户端计算机进行多媒体的播放和观看，其中下载的内容只是暂存在缓存区，播放后即可进行释放，这样可以节省客户端的缓存及硬盘空间。

3）缩短了延时等待的时间。大大的提高了系统运行的效率，减少了视频缓冲时间，使得网络视频教学播放的更为流畅。

4）采用了与以往不同的传输。流媒体技术应用一种实时传输协议，这一协议较好的解决流媒体数据传输问题，可以使媒体数据在网上快速有效的传输。针对.rm，.avi，.flv，.swf等格式的动画视频提供在线播放功能，能自动识别视频格式，选择对应的网页播放器，在带宽不足的情况下，能够实现同时在线的人数控制。相对于传统的下载后播放大幅度，流式传输减少了启动延时，且由于所有内容都被下载到缓存中，使得所需空间大大减少。目前，流式传输主要依靠以下两种方式实现：一是实时流式传输（RealtimeStreaming），二是顺序流式传输（ProgressiveStreaming）。如视频为实时广播，可以使用流式传输媒体服务器或者使用RTSP这样的专门设计的实时协议，如果使用HTTP传输，文件则是顺序流传输。

1）顺序流式传输顺序流式传输指的是顺序下载媒体文件，用户只能观看已下载部分却不能跳至未下载部分，由于HTTP协议本身存在限制，该传输方式亦不能根据带宽情况在传输期间进行调整。通常情况下，HTTP服务器可发送此类文件形式，所以该方式也称作HTTP流传输。

2）实时流式传输实时流式传输不同于顺序流式传输，它采用专门的流媒体服务器及传输协议，实时流媒体支持随机访问，可对观看内容快进和后退。特定流媒体服务器在实时流式传输中是必要的，如DarwinStreamingServer、HelixServer与WindowsMediaServer。这些服务器允许更多级别的控制媒体发送。特殊网络协议在实时流式传输中也是必要的，如：RTSP（RealtimeStreamingProtocol）或MMS。

2结语

文件传输协议范文

关键词USB；CAN；BOOTLOADER

中图分类号：TP29文献标识码：A文章编号：1671-7597（2013）11-0000-00

1系统结构

Can-bootloader的实现基于如图1所示系统环境结构。

图1

其中：

USB-CAN转接卡：实现USB总线到CAN总线的协议转换，通过该设备实现BCU的can总线与PC机的数据通信。

下位机板卡：运行bootloader软件，接收S19镜像文件。

PC机（windows）：运行上位机程序，向BCU发送S19镜像文件。

2通信协议

BOOTLOADER通过CAN总线与USB-CAN卡通信，BOOTLOADER通过CAN总线接收从PC机发送过来的S19镜像文件（通过USB-CAN卡）进行BOOTLOADER的flash烧写。

整个通信协议基于文本传输格式的异步文件传输协议，PC机和CAN卡之间以128字节块的形式传输数据，CAN卡与BOOTLOADER之间以8字节的形式传输数据，采用应答传输机制来配合USB高速端的流控，CAN卡将PC机传输过来的数据块以8字节发送，发完一整包（128字节）的数据后以ACK的形式通知PC机可以发送下一包数据。

2.1上位机与CAN卡通信协议

上位机与CAN卡之间通过USB总线连接，USB-CAN卡被windows识别为普通USB设备，上位机应用程序调用CAN卡的windows驱动程序进行数据读写，数据包长（含包头）最大为128byte。具体实施协议如下所述（USB总线物理层具备CRC校验，所以协议不需对数据进行校验。

2.1.1协议包数据格式

协议数据包格式如图2所示。

图2

其中包长、包序号、标志皆为1byte，数据为0～125byte。具体含义如下：

包长：指示本包数据长度

包序号：指示本包序列号，第一包序号约定为1，后续序号在0～255间循环。

标志：指示本包数据是否为待传输文件的最后一包，若是起始包将标志置1，最后一包将标志置2，其他置0。

2.1.2确认包格式

确认包为接收方收到正确的数据后向发送方传输，固定为1byte，值为0x0x06。#defineACK0x06。

2.2CAN卡与BOOTLOADER通信协议

CAN卡与BOOTLOADER之间数据包长固定为8字节。具体实施协议如下所述：

2.2.1协议数据包格式

（每个数据包含有125字节数据）

协议数据包格式如图3所示。

图3

传输文件用到的基本数据包大小为125字节，若待传输文件的大小不是125字节的整数倍，那么最后一包数据报文的长度不足部分需以CTRLZ填充报文。

2.2.2协议相关控制字符

（文件以文本格式传送，以下控制字符不占用128个ascii码）

SOH0x01；EOT0x04

ACK0x06；NAK0x15

CAN0x18；CTRLZ0x1A

2.2.3协议传输概述

传输启动：

协议传输由数据接收方发起，接收方通过向发送方发送NAK报文，发送方收到后进入发送流程。

传输过程：

当发送方接收到接收方发送的第一个NAK后，发送方进入协议的传输过程，进入传输过程后发送方需将待传送数据按照图3所示数据包格式打包，最后将打包的成帧数据包传送。

数据的发送接收采用ACK确认机制，发送方发送一包数据后需等待接收方的确认ACK，收到ACK后发送方才能继续发送数据；若通信的过程中发送方有可能收到NAK或CAN字节的异常处理报文，其中NAK表示接收方请求重发当前报文，CAN字节表示接收方请求停止传输。

结束传输：

如果收发通信双方传输正常，发送方需向接收方发送EOT字节以通知接受方传输正常结束。接受方收到EOT字节之后需回送ACK进行确认。当然在结束传输的过程中接收方也可以发送CAN字节来强制停止传输（发送方收到CAN字节后不需再发EOT确认）。

3USB-CAN转接卡设计

3.1USB从设备驱动设计

USB总线中的通信包含以下四种：控制传输、批量传输、中断传输、定时传输等四种。USB设备的枚举过程采用的就是控制传输。从设备枚举成功后，本设计的数据传输方案采用USB规范定义的中断传输和批量传输两种传输方式来传输数据，其中中断传输用于收发控制数据，而批量传输用于传输数据。

其中控制传输是重点和难点，当从设备插入USB集线器时，主机向从设备发送一个获取状态命令请求来验证设备是否激起重启状态。设备现在使用默认地址0x0与主机通信。通信流程如下所述：

1）主机通过默认地址0x0发送USB协议中的获取设备描述符命令以获取控制传输管道的基本参数（最大数据包长等）。

2）主机发送设置地址命令给设备请求分配新的地址，请求成功后设备端保存新地址（此后的通信都通过这个新地址进行通信）。

3）主机通过新地址发送获取设备描述符命令，获取设备描述符的完整信息（如VID、PID等）。

4）主机通过新地址发送获取设备配置命令，获取设备的配置信息。此时主机提示加载新设备驱动程序后，主机发送设置配置命令为设备选择合适的配置参数，配置成功后，设备就可以通过应用软件进行数据传输阶段的通信了。

数据传输阶段较简单，只需对相应的数据端点寄存器进行读写即可完成数据的收发。

3.2CAN驱动设计

CAN控制器采用SJA1000，SJA1000支持BasicCan和PeliCan两种模式。其中PeliCan模式功能强大、支持多种滤波方式，本设计采用PeliCan模式。上位机通过USB发送应用程序镜像（具体实现见上述通信协议），BOOTLOADER解析协议，完成镜像的烧写，最终能通过USB-CAN卡实现对多点CAN网络进行指定节点的应用程序烧写。

3.3windows驱动及应用软件设计

USB的windows驱动采用DriverStudio2.6DDK，启动DDK后选择WDM类型，再选择USB总线类型、并设置好VID和PID，最后设置好各个端点地址、端点传输类型、最大包长等选项后，完成USB驱动的框架，在读写函数中加入驱动的数据处理部分后即可完成驱动的设计（生成inf和sys文件），最终驱动程序读写部分打包为DLL文件以便上位机应用程序调用，应用程序协议处理较简单（参看上述协议部分），最终程序界面如图4所示。

4CAN-BOOTLOADER设计

4.1BOOTLOADER结构

BOOTLOADER结构如图5所示。

各区在FLASH中的地址范围如下：

应用程序区+应用程序中断向量表：0x7843ff～0x7f3fff、0x7f83ff～0x7fffff

BOOTLOADER区+BOOTLOADER中断向量表：0x7803ff～0x783fff、0x7f43ff～0x7f7fff

程序复位首先进入bootloader，进入后由bootloader管理中断向量表，将应用程序中单片机的默认中断向量整体映射到bootloader中断向量表中，进入应用程序后bootloader交出管理权由应用程序管理使用单片机默认的中断向量表。

4.2程序结构及处理流程

Bootloader处理的镜像文件格式采用S19格式，S19的文件格式解析是完成烧写的重要组成部分，S19文件是摩托罗拉公司为便于对可执行镜像文件便于烧写而提出的一种文件格式。其中开发的重心集中在烧写APP命令的处理，Bootloader接收到编程命令后，进入CAN通信自定义协议接收流程，bootloader收到128字节块存入缓冲区后根据图中所示状态机解析出S19文件的完整一行数据，将该行烧入FLASH；烧写成功后继续协议的下一个128字节块的数据接收；当收到S19文件的最后一行时完成对整个S19文件烧写处理流程，协议接收到128字节数据后的流程处理如图7所示。

5结束语

本文基思卡尔MC9S12系列开发的bootloader，实现了单片机bootloader所需的大部分功能，且软件模块划分合理、设计思路清晰；同时串口通信协议采用标准的xmodem协议，具备一定的通用性，对其它架构的单片机或处理器设计开发bootloader亦有一定的参考价值。

参考文献

[1]MC9S12XEP100ReferenceManualCoversMC9S12XEFamily.

[2]邵贝贝.嵌入式系统中的双核技术[M].北京：北京航空航天大学出版社，2008.

作者简介

万礼华（1974-），男，汉族，重庆市沙坪坝区人，高级工程师，硕士，研究方向：轨道交通闸机通行控制算法，汽车电子控制器，短波自适应通数字电台，综合交换调度设备等。