CN114244833B - 一种采用ftp协议实时传输遥感卫星原始数据的方法 - Google Patents

Abstract

本发明提供一种采用FTP协议实时传输遥感卫星原始数据的方法，采用FTP协议代替采用自定义的实时传输协议，实时传输符合国家推荐标准的遥感卫星原始数据，在发送端部署FTP客户端程序，在接收端部署FTP服务器程序并进行FTP服务器相应设置，包括：将遥感卫星原始数据分解为第一信息数据和第二信息数据；客户端通过FTP协议先后向FTP服务器发送传输任务对应的描述文件、第二信息数据和第一信息数据文件以及传输结束标示文件；FTP服务器接收到以上文件之后，基于第一信息数据和第二信息数据合成遥感卫星原始数据文件，完成遥感卫星原始数据的实时传输。本发明能够减少实时传输遥感卫星原始数据的复杂性以及错误率，从而提高传输效率。

Description

一种采用FTP协议实时传输遥感卫星原始数据的方法

技术领域

本发明涉及遥感卫星技术领域，尤其涉及一种采用FTP协议实时传输遥感卫星原始数据的方法。

背景技术

遥感卫星接收系统中记录系统实时记录遥感卫星下传的卫星原始数据，按照国家推荐标准《遥感卫星原始数据记录与交换格式》，国家标准（GB/T 31011-2014）记录成卫星原始数据文件或者数据流，通过非实时或实时的方式推送给下游系统，完成遥感卫星原始数据的非实时或实时传输。

目前，对于遥感卫星原始数据的实时传输要求，采用自定义的实时传输协议，在记录系统中编写特定socket客户端发送程序，在数据传输系统中编写特定socket服务端接收程序，根据协议要求完成实时数据传输。由于采用不同的传输协议，造成了非实时传输协议与实时传输协议不同的实现方式。

从“原始数据实时传输协议”看，自定义的实时传输协议非常复杂，对实时传输的下游系统提出了特殊的应答和反馈要求，需要记录系统和下游的数据传输系统开发特定的实时传输软件，还要实现断点续传、网络负载均衡等复杂的功能，实现的过程比较困难并且容易出错。

因此，如何使实时传输遥感卫星原始数据的过程变得容易且减少错误率，是当前课题亟需解决的技术问题。

首先，介绍现有的国家推荐标准《遥感卫星原始数据记录与交换格式》原始数据内容和格式要求、非实时传输要求、实时传输要求，进一步分析存在的问题，并提出解决思路。

《遥感卫星原始数据记录与交换格式》要求内容包括三部分：数据头信息、辅助信息、原始数据。以下对数据头信息、辅助信息和原始信息做详细介绍。

一、数据头信息：

数据头信息描述了与本次记录数据相关的信息。主要内容包括：格式ID、版本号、接收站名和主要设备名称、星别、轨道编号、记录数据的起始与终止时间、卫星下行通道总数、数据块尺寸编码、数据排列方式等。

描述数据头信息的各字段内容为字符串类型，采用ASCII编码。数据头信息位于数据文件的开始位置。以字节为单位，其相对地址是从0到65535，占用存储空间65536字节。

数据头信息中包含用以描述不同方面信息的多个字段，除本标准已定义的字段外，其余为备用空间，备用空间填充字符0x20（即ASCII字符“空格”）。

数据头信息区的具体格式规定见下表1：

二、辅助信息：

辅助信息描述本次记录文件（一轨卫星数据）各个数据块所对应的时间信息和数据块编号等信息。

辅助信息均采用十六进制整型数据。辅助信息存储位置：从数据头信息的结束位置相对地址65536字节起，至相对地址4194304字节终，共占用空间4128768字节。每条辅助信息占16字节，最多容纳258048条辅助信息，没有用到的空间填充0x00。

辅助信息的相对地址排列顺序见下表2：

在辅助信息区内将每个原始数据块对应一条辅助信息，将一轨数据所有辅助信息集中成为一体，形成辅助数据区的内容。

每条辅助信息中的时间信息对应每块数据第一个字节的起始时间。辅助信息顺序排列。辅助信息格式见下表3：

三、原始数据：

原始数据采用十六进制整型数据，相对地址从4194304字节起顺序排列。采取按块划分的原则，每块数据对应辅助信息部分中的一条辅助信息。原始数据存储格式见下表4：

针对一颗卫星以多个下行通道发送数据的情况，按照每个通道形成为一个数据文件，多通道的数据形成多个文件，并由多个文件的文件名来加以区分。

其中，上述表1中的“实际记录终止时间”在该轨记录完成之后才能确定，表2中的各条辅助信息中的时间信息随着原始数据的记录时间增长不断增加和确定下来。以上信息作为4M原始数据的头部信息，在实时传输的开始的时候是不能确定的。无法作为记录与交换格式规定的前4M数据实时传输给下游系统。

以下对非实时传输规范要求进行简要概述：

非实时传输的传输协议为FTP，通信端口为21，采用主动文件上传方式，即文件发送方使用正确的用户名和口令登录FTP服务器后，自动将要传输的文件上载到FTP服务器指定的目录。

同一个任务单的多个文件进行非实时传输之前，先需要在目标FTP目录下创建一个子文件目录JobTaskID（任务编号），再在该目录下创建任务描述文件，以描述本次任务应当传输的文件列表。

文件名为：JobTaskID.DESC

其中，JobTaskID为替换值，使用时应替换为实际的任务编号。

文件内容为：

GF01_01_002010_20130901_MY100_R0.dat 文件大小（字节）；

GF01_02_002010_20130901_MY101_R0.dat 文件大小（字节）。

其中文件名和文件大小之间采用“Tab”制表符分隔。

以上的文件路径，应当是以传输目标FTP目录为起点（不含）的相对路径。

所有文件传输完成之后，则应当在目标FTP子目录JobTaskID下创建一个传输结束文件，该文件内容为空，文件名为：JobTaskID.OK。

以下对现有技术中的实时传输协议要求进行详细描述：

从非实时传输协议要求来看，利用FTP协议、加上JobTaskID、JobTaskID.DESC、JobTaskID.OK等约定文件或者目录，简单明了的完成了原始数据向下游系统的非实时传输过程。但是对于实时传输协议来说，如果使用自定义的传输协议，需要以下复杂的“原始数据实时传输协议”。

原始数据实时传输协议文本的描述如下：

1.1、原始数据实时传输协议概述：

原始数据实时传输协议是作为地面数据接收系统内数据传输分系统与相关系统间的原始数据实时传输接口定义。利用该协议实现实时地将卫星下传数据从记录与快视子系统传输至数据传输分系统、数据传输分系统传输至地面数据接收系统外部系统，并按照《附录一 原始数据记录与交换格式》要求对数据进行格式化，同时，支持“断点续传”。

所谓断点续传，是指在实时传输过程中，如果出现网络中断，实时传输协议会保证记住数据传输的中断位置，当网络恢复正常时，发送端会从中断位置继续发送数据。

本协议基于TCP协议，发送端对应TCP协议的客户端，接收端对应TCP协议的服务器端。

本协议针对小字节序（little-endian，低字节在前）设计，传输逻辑单元是帧，下面详细介绍帧的数据结构，及如何使用。

1.2、帧的概述：以下参照图1-11，对帧结构进行概述。图中，frame type表示帧类型，data type表示数据类型，frame counter表示帧计数器，data length表示数据长度，reserved表示接收。

1.2.1、帧结构的概述：

参照图1，帧结构由帧头和数据区组成。帧头长度是固定值，为24个字节，数据区长度不是定值，由帧头内的DataLength来确定。

帧头由四个描述区和一个保留区组成，每个描述区都为4个字节，总共16个字节；保留区为8个字节。由低地址到高地址分别为，FrameType(帧类型)、DataType(数据类型)、FrameCounter(帧计数)、DataLength(有效数据长度)和Reserverd(保留区)。其中，数据区为实际传输的有效数据。

帧结构内容如下表5所示：

DataType值(十六进制)如下表6所示：

1.2.2、帧头描述区：

（1）FrameType(帧类型)：

标识帧的起始，为定值。发送端发送的每一帧都应该填写此区。接收端通过该区来识别一个帧的起始。

（2）DataType(数据类型)：

描述帧的数据类型，填写方法参照表2 DataType值表。 在一次传输开始前，发送端应首先发送“负载均衡真实传输IP地址请求”，接收端收到此请求后应给予“真实IP”；接着发送端发送“传输请求”，接收端收到此请求后应给予“标准应答”；然后发送端依次发送“填充格式头”、“填充格式辅助信息”、“数据”、“有效格式头”、“有效格式辅助信息”，当发送端想要结束传输时，就发送“空帧”，接收端收到此帧后就关闭连接；当传输过程中出现中断，一旦网络恢复正常，发送端应首先发送“续传请求”，接收端收到此帧后，应给予“标准应答”，然后继续传输。

（3）FrameCounter(帧计数)

帧计数用于辅助接收端对收到的帧数据进行排序，发送端将卫星下传数据分块发送至接收端，这些帧的计数是按照表1帧结构内容中的“帧计数”填写的。

“断点续传”时，发送端发送的第一帧是“续传请求”帧，该帧的计数为0，紧接的下一帧是“数据”帧，该帧的计数应该是发送端在“续传请求”后所接收到的标准应答帧中填写的帧计数值，此原理可以参考标准应答帧的说明。

（4）DataLength(有效数据长度)

unsigned int类型，其值表示数据区的字节数。

1.2.3、帧数据区：

帧的数据区用于存放有效数据，接收端将这些有效数据组织成记录文件。根据不同的帧数据类型，即DataType不同值，帧的数据区的格式和内容有一定的区别。

不同类型帧的数据区格式及内容，如下表7所示：

1.3、帧的类型：

1.3.1、传输请求帧：

参照图2，图2为传输请求帧的样例，包括帧头和数据区，订单号为JOB201110260000027，包含文件名“HJ1C_S1_000114_20080522_MY431_R0”的传输请求帧。文件名占用33字节（包含’\0’），数据区占用66个字节。其中：

0~17字节：JobTaskID，总共18字节，字符串，无NULL结尾字符，如JOB201110260000027；

18~21字节：卫星名，共4字节，字符串，无NULL结尾字符，如HJ1C；

22~23字节：传感器名，共2字节，字符串，无NULL结尾字符，如S1；

24~25字节：轨道号，共2字节，无符号整数（小字节序）；

26字节：通道号，共1字节，无符号整数；

27字节：本任务单传输（记录）文件总数，共1字节，无符号整数；

28字节：本次传输的文件在所属任务中的文件序号，共1字节，无符号整数；

29~32字节：本次传输的文件名长度，共4字节，整数，目前应为固定值33（含文件名结尾NULL字符）；

33~65字节：本次传输的文件名，共33字节，字符串，含结尾NULL字符，编码是GB2312。

传输请求帧由发送端发起。记录文件名按照原始数据记录与交换格式，根据实际卫星数据记录情况生成。

1.3.2、填充格式头帧：

参照图3，图3为填充格式头帧的样例，包括帧头和数据区；格式头占用64KByte，即65536字节，填充格式头帧数据区保留65536个字节，内容填0。接收端收到此帧后，直接将数据区写入磁盘作为空格式的数据头信息，也就是起到“占位”的作用。

1.3.3、填充格式辅助信息帧：

参照图4，图4是填充格式辅助信息帧的样例，包括帧头和数据区；辅助信息区共占用4128768字节，填充格式辅助信息帧的数据区保留4128768字节，内容填0。接收端收到此帧后，直接将数据区写入磁盘作为空格式的数据辅助信息，起到“占位”的作用。

1.3.4、数据帧：

参照图5，图5为数据帧的样例，包括帧头和数据区；数据帧是有效数据的载体，“FrameCounter”域从3开始顺序计数，“DataLength”域填写的值表示数据区内的字节数，此值是可变的。根据原始数据记录与交换格式的要求，数据帧中数据区最大值为16M。样例展示的是一个数据区长度为256KB的数据帧。

1.3.5、有效格式头帧：

参照图6，图6为有效格式头帧，包括帧头和数据区；根据实际情况填写原始数据记录与交换格式的数据头信息，等待卫星数据发送到接收端全部完毕后，将填写好的有效格式头帧发送到接收端。接收端收到此帧后，只须将此帧数据区的内容直接覆盖填充格式头帧写盘的位置即可。

1.3.6、有效格式辅助信息帧：

参照图7，图7为有效格式辅助信息帧的样例，包括帧头和数据区；发送端在接收卫星数据时，根据实际情况填写原始数据记录与交换格式的辅助信息，等待有效格式头帧发送完毕后，将填写好的有效格式辅助信息帧发送到接收端。接收端收到此帧后，只须将此帧数据区的内容直接覆盖填充格式辅助信息帧写盘的位置即可。

1.3.7、空帧：

参照图8，图8为空帧的样例，包括帧头；当有效格式辅助信息帧传输完毕后，发送端发送一个空帧，以此通知接收端此次传输结束，空帧没有数据区。

1.3.8、续传请求帧：

参照图9，图9为续传请求帧的样例，包括帧头和数据区；续传请求帧由发送端发起，用于在网络中断恢复后，发送端向接收端发起续传请求。此帧的“FrameCounter”域填写0，数据区填写续传文件的文件名，填写规则是首先填写4字节的文件名长度，然后填写GB2312编码的文件名，包含字符串结束符标志“\0”。

此样例展示了，某次以“HJ1C_S1_000114_20080522_MY431_R0”为记录文件名的传输中断后，发送端填写的续传请求帧。

1.3.9、标准应答帧：

参照图10，图10为标准应答帧的样例，包括帧头和数据区；标准应答帧由接收端发出，以应答发送端的传输请求帧或者续传请求帧。此帧数据区有4个字节，作为int类型，1表示应答成功，-1表示应答失败。接收端在尚未准备好时，可以发送应答失败。发送端只有收到成功应答才可以继续发送，如果收到了应答失败，那么将每隔一段时间发送一次请求帧。

当“断点续传”发生时，接收端所发出的标准应答帧需要在“FrameCounter”域中填写“中断帧计数+1”，同时在“Reserved”域填写8字节的“中断接收字节数+1”。这样，发送端收到此标准应答帧后就可以根据这两个域中的内容判断出中断位置。

1.3.10、负载均衡真实IP传输请求帧：

参照图11，图11为负载均衡真实IP传输请求帧的样例，包括帧头和数据区；负载均衡真实IP格式与传输请求帧保持一致，唯有传输帧类型不同；负载均衡真实IP格式与传输请求帧除传输帧头信息，其他部分可进行填充。

1.3.11、负载均衡真实IP应答：

负载均衡真实IP应答为16字节IP信息，格式“xxx.xxx.xxx.xxx\0”。

1.4、传输时序：

在一次传输开始前，发送端应首先发送“负载均衡真实传输IP地址请求”，接收端收到此请求后应给予“真实IP”；接着发送“传输请求”，接收端收到此请求后应给予“标准应答”；然后发送端依次发送“填充格式头”、“填充格式辅助信息”、“数据”、“有效格式头”、“有效格式辅助信息”，当发送端想要结束传输时，就发送“空帧”，接收端收到此帧后就关闭连接；当传输过程中出现中断，一旦网络恢复正常，发送端应首先发送“续传请求”，接收端收到此帧后，应给予“标准应答”，然后继续传输。

参照图12，图12为发送端和接收端实时传输流程图，两边的每一个步骤大体上按照时间对应起来，发送端和接收端的应用程序设计可以参考此图。

发送端的实时传输流程为：

发送负载均衡请求帧；

接收真实IP；

发送传输请求帧；

收到标准应答帧；

判断应答是否成功，若不成功则返回发送传输请求帧，若成功则发送填充格式头帧；

发送填充格式辅助信息帧；

发送数据帧；

判断网络是否中断，若网络没中断，则判断发送是否完毕，若网络中断则重新连接；若没有发送完毕，则返回发送数据帧；若发送完毕，则发送有效格式头帧、有效格式辅助信息帧和空帧，结束流程；

重新连接之后判断网络是否恢复，若未恢复则继续重新连接，若恢复则发送续传请求帧，收到标准应答帧，并判断应答是否成功，若成功则返回发送数据帧，若不成功则返回发送续传请求帧。

相应地，接收端的实时传输流程为：

接收负载均衡请求帧；

发送真实IP；

收到传输请求帧；

判断是否准备就绪，若没有准备就绪则发送失败应答帧，并返回收到传输请求；若准备就绪则发送成功应答帧；

收到填充格式头帧；

收到填充格式辅助信息帧；

收到数据帧；

判断网络是否中断，若网络没中断，则判断是否收到空帧，若收到则结束流程；若没有收到空帧，则返回收到数据帧；

如网络中断，则重新建立连接，并判断网络是否恢复，若未恢复则继续重新连接，若恢复则收到续传请求帧，并判断是否准备就绪，若是则发送成应答帧，若否则返回发送失败应答帧。

另外，发送端和接收端在传输“开始”步骤之前的TCP连接建立过程规定如下：

接收端在指定端口(10086)监听请求，发送端主动连接接收端的指定端口，建立起TCP连接。连接建立好后，实时传输协议就基于此连接完成。一个接收端可以建立多个连接，每一个连接对应一个传输任务。

发送端和接收端在传输“结束”步骤之后的过程规定如下：

在传输完毕后，接收端在收到空帧后就可以关闭TCP连接，如果由于异常原因未能收到空帧，那么接收端应该在超时一段时间后关闭连接并退出，超时具体时间根据实际情况设定。发送端在发送空帧后就可以关闭TCP连接并退出。

1.5、断点续传过程：

在实时传输过程中，当出现网络中断时，发送端停止发送，在网络中断期间，发送端应每隔一段时间检测网络的状态，当发现网络恢复后，便向接收端发送续传请求帧。

接收端在接收数据的过程中，实时记录当前收到的帧计数和数据总字节数。一旦出现网络中断，就确定当时为中断帧计数和中断接收字节数。

接收端在网络中断期间，每隔一段时间检测网络的状态，当发现网络恢复后，就重新在指定端口监听。此时接收端应收到发送端发来的续传请求帧，如果此时没有准备好，那么应该发送一个标记“失败”的标准应答帧给发送端。如果可以继续工作了，那么发送一个标记“成功”的标准应答帧给发送端，此应答帧的“FrameCounter”域填写中断帧计数，“Reserved”域填写中断接收字节数。

发送端收到标准应答帧后，首先判断是什么类型的标准应答帧，即如果是“失败”的标准应答帧，那么表示接收端没有准备好，那么发送端等待一段时间后，重新发送续传请求帧。如果是“成功”的标准应答帧，那么表示接收端可以继续接收数据了，那么发送端从标准应答帧中读取中断帧计数和中断接收字节数，判断中断位置，并从中断位置重新发送数据帧。

按照以上原理完成一次断点续传过程，如果网络再次中断，那么继续按照此原理进行断点续传。

发明内容

本发明提供一种采用FTP协议实时传输遥感卫星原始数据的方法，用以解决现有技术中实时传输遥感卫星原始数据自定义传输协议复杂并且容易出错的缺陷，实现提高遥感卫星原始数据实时传输的效率。

本发明提供一种采用FTP协议实时传输遥感卫星原始数据的方法，采用FTP协议代替采用自定义的实时传输协议，实时传输符合国家推荐标准的遥感卫星原始数据，在发送端部署FTP客户端程序，在接收端部署FTP服务器程序并进行FTP服务器相应设置，所述方法包括：

客户端将遥感卫星原始数据分解为第一信息数据和第二信息数据；其中所述第一信息数据包括数据头信息和辅助信息，所述第二信息数据包括原始数据信息；

客户端向FTP服务器发送创建请求，所述FTP服务器接收到客户端发送的创建请求之后，创建表示传输任务的子文件目录，并在所述子文件目录下创建与所述传输任务对应的描述文件；

客户端通过FTP协议先后向FTP服务器发送所述传输任务对应的描述文件、第二信息数据和第一信息数据文件以及传输结束标示文件；

FTP服务器接收到以上文件之后，基于第一信息数据和第二信息数据合成遥感卫星原始数据文件，完成遥感卫星原始数据的实时传输。

根据本发明提供的一种采用FTP协议实时传输遥感卫星原始数据的方法，所述客户端将遥感卫星原始数据分解为第一信息数据和第二信息数据，具体包括：

客户端将遥感卫星原始数据分解为多个第一信息数据和多个第二信息数据；

所述基于第一信息数据和第二信息数据合成遥感卫星原始数据文件，具体包括：

基于多个第一信息数据和多个第二信息数据合成遥感卫星原始数据文件。

根据本发明提供的一种采用FTP协议实时传输遥感卫星原始数据的方法，所述客户端通过FTP协议先后向FTP服务器发送所述传输任务对应的描述文件、第二信息数据和第一信息数据文件以及传输结束标示文件，具体包括：

客户端通过FTP协议向FTP服务器发送所述传输任务对应的描述文件和传输结束标示文件，以及先后发送多个第二信息数据和多个第一信息数据文件。

根据本发明提供的一种采用FTP协议实时传输遥感卫星原始数据的方法，所述方法还包括：存在逐个环节依次进行遥感卫星原始数据实时传输的情况下，每个环节的客户端同时通过FTP协议向每个环节的FTP 服务器传输第二信息数据；

每个FTP服务器接收客户端传输的所有第二信息数据之后，每个客户端再向所述FTP服务器补传遥感卫星原始数据的第一信息数据，并结合第二信息数据合成遥感卫星原始数据文件。

根据本发明提供的一种采用FTP协议实时传输遥感卫星原始数据的方法，存在多台FTP服务器的情况下，所述方法还包括：

利用FTP协议的被动模式结合LVS，通过虚拟IP地址，实现对多台FTP服务器传输的负载均衡功能。

本发明提供的采用FTP协议实时传输遥感卫星原始数据的方法，将客户端和服务器通过FTP协议建立，在FTP服务器下创建子文件目录，并在子文件目录下创建描述文件，通过FTP协议进行遥感卫星原始数据的传输，将接收到的数据记录在FTP服务器下，并根据接收到的第一信息数据和第二信息数据合成传输结束文件，从而完成遥感卫星原始数据的实时传输。本发明能够减少实时传输遥感卫星原始数据的复杂性以及错误率，从而提高传输效率。

附图说明

为了更清楚地说明本发明或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是帧的数据结构示意图；

图2是传输请求帧样例；

图3是填充格式头帧样例；

图4是填充格式辅助信息样例；

图5是数据帧样例；

图6是有效格式头帧样例；

图7是有效格式辅助信息帧样例；

图8是空帧样例；

图9是续传请求帧样例；

图10是标准应答帧样例；

图11是负载均衡真实IP传输请求帧；

图12是现有技术中发送端和接收端实时传输流程图；

图13是本发明提供的一种采用FTP协议实时传输遥感卫星原始数据的方法的流程示意图之一；

图14是本发明提供的一种采用FTP协议实时传输遥感卫星原始数据的方法的流程示意图之二。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合本发明中的附图，对本发明中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

下面结合图13-图14描述本发明提供的一种采用FTP协议实时传输遥感卫星原始数据的方法。

参照图13，本发明提供一种采用FTP协议实时传输遥感卫星原始数据的方法，采用FTP协议（File Transfer Protocol）代替采用自定义的实时传输协议，实时传输符合国家推荐标准的遥感卫星原始数据，在发送端部署FTP客户端程序，在接收端部署FTP服务器程序并进行FTP服务器相应设置，所述方法包括以下步骤：

步骤131、客户端将遥感卫星原始数据分解为第一信息数据和第二信息数据；其中所述第一信息数据包括数据头信息和辅助信息，所述第二信息数据包括原始数据信息；

具体地，把遥感卫星原始数据（记为x.dat）根据数据头信息、辅助信息、原始数据三部分，分解为两部分，第一部分包含数据头信息、辅助信息，定义为4M头部数据即第一信息数据，记为x.4M；第二部分包含原始数据信息，定义为裸数据部分即第二信息数据，记为x.raw。x.4M+x.raw＝x.dat。

步骤132、客户端向FTP服务器发送创建请求，所述FTP服务器接收到客户端发送的创建请求之后，创建表示传输任务的子文件目录，并在所述子文件目录下创建与所述传输任务对应的描述文件；

具体地，本实施例中需要向FTP服务器的目录下创建一个子文件目录JobTaskID，再在该目录下创建任务描述文件，以描述本次任务应当传输的文件列表。

文件名为：JobTaskID.DESC；

其中，JobTaskID为替换值，使用时应替换为实际的任务编号。

文件内容为：

GF01_01_002010_20130901_MY100_R0.raw；

GF01_01_002010_20130901_MY100_R0.4M；

GF01_02_002010_20130901_MY101_R0.raw；

GF01_02_002010_20130901_MY101_R0.4M。

步骤133、客户端通过FTP协议先后向FTP服务器发送所述传输任务对应的描述文件、第二信息数据和第一信息数据文件以及传输结束标示文件；

具体地，将描述文件通过FTP协议进行实时传输，并将描述文件记录在FTP服务器下。在传输过程中，由于根据国家推荐标准的约束，第二信息数据为遥感卫星原始数据的实际数据，FTP服务器需要先接收实际数据，再接收实际数据在记录过程中形成的外加元数据，即第一信息数据。因此，客户端需要依次通过FTP协议向FTP服务器实时传输描述文件、第二信息数据、第一信息数据以及结束标示文件。

在记录过程中，边记录边开始以FTP协议实时传输接收到的x.raw数据到相应的服务器目录下，在记录完成后，再传输相应的x.4M头部数据，此时x.4M头部数据已经形成，是完整数据了。所有文件传输完成之后，则在FTP服务器的子文件目录JobTaskID下创建一个传输结束文件，该文件内容为空，文件名为：JobTaskID.OK。

步骤134、FTP服务器接收到以上文件之后，基于第一信息数据和第二信息数据合成遥感卫星原始数据文件，完成遥感卫星原始数据的实时传输。

具体地，本实施例中的第一信息数据和第二信息数据分别指的是x.4M和x.raw文件，而结束标示即为x.dat文件。客户端向服务器端发送传输结束请求，服务器端程序检索到JobTaskID.OK文件，把x.4M和x.raw文件拼接合成为x.dat文件，形成符合国家推荐标准格式的原始数据。至此，完成遥感卫星原始数据从数据记录系统到下游系统的实时传输任务。

本发明提供的采用FTP协议实时传输遥感卫星原始数据的方法，将客户端和服务器通过FTP协议建立，在FTP服务器下创建子文件目录，并在子文件目录下创建描述文件，通过FTP协议进行遥感卫星原始数据的传输，将接收到的数据记录在FTP服务器下，并根据接收到的第一信息数据和第二信息数据合成传输结束文件，从而完成遥感卫星原始数据的实时传输。本发明能够减少实时传输遥感卫星原始数据的复杂性以及错误率，从而提高传输效率。

基于以上实施例，所述客户端将遥感卫星原始数据分解为第一信息数据和第二信息数据，具体包括：

客户端将遥感卫星原始数据分解为多个第一信息数据和多个第二信息数据；

所述基于第一信息数据和第二信息数据合成遥感卫星原始数据文件，具体包括：

基于多个第一信息数据和多个第二信息数据合成遥感卫星原始数据文件。

基于以上实施例，所述客户端通过FTP协议先后向FTP服务器发送所述传输任务对应的描述文件、第二信息数据和第一信息数据文件以及传输结束标示文件，具体包括：

客户端通过FTP协议向FTP服务器发送所述传输任务对应的描述文件和传输结束标示文件，以及先后发送多个第二信息数据和多个第一信息数据文件。

基于以上实施例，所述方法还包括：存在逐个环节依次进行遥感卫星原始数据实时传输的情况下，每个环节的客户端同时通过FTP协议向每个环节的FTP 服务器传输第二信息数据；

每个FTP服务器接收客户端传输的所有第二信息数据之后，每个客户端再向所述FTP服务器补传遥感卫星原始数据的第一信息数据，并结合第二信息数据合成遥感卫星原始数据文件。

具体地，第一信息数据是实际卫星数据，第一信息数据在记录过程中形成的外加的元数据信息，不是该遥感卫星数据的必须信息，可以灵活处理x.4M数据，提高实时传输的时效性。如果有多个实时传输环节，各个环节均可以依照步骤131、132启动实时传输x.raw数据，随后补传x.4M数据，在最后一个传输环节合成x.dat即可。这样就不会影响各个环节实时传输的时效性，做到多个环节的实时传输。

本实施例在实际传输场景中，多地点接力进行遥感卫星原始数据的实时传输时，通过在每个地点设置传输环节同时基于FTP协议进行遥感卫星原始数据的实时传输，能够提高多个环节实时传输的实效性。

基于以上实施例，存在多台FTP服务器的情况下，所述方法还包括：

利用FTP协议的被动模式结合LVS，通过虚拟IP地址，实现对多台FTP服务器传输的负载均衡功能。

以下对本发明提供的一种采用FTP协议实时传输遥感卫星原始数据的方法进行举例描述：

参照图14，以下基于客户端和服务器端的双端信息交互，对本发明提供的一种采用FTP协议实时传输遥感卫星原始数据的方法进行描述。包括以下步骤：

步骤141，客户端向FTP服务器发送创建请求；

步骤142，服务器端基于创建请求创建表示传输任务的子文件目录，并在所述子文件目录下创建与所述传输任务对应的描述文件；

步骤143，客户端基于FTP协议先后实时向服务器端传输描述文件、x.raw、x.4M文件并向服务器端发送数据记录请求；

步骤144，服务器端将x.4M、x.raw文件记录在FTP服务器下；

步骤145，客户端向服务器端发送传输结束请求；

步骤146，FTP服务器基于传输结束请求创建传输结束文件;

步骤147，服务器端基于x.4M和x.raw生成x.dat，完成遥感卫星原始数据的实时传输。

以下结合具体实例，对本发明提供的采用FTP协议实时传输遥感卫星原始数据的方法进行描述：

实时传输某轨卫星原始的JobTaskID为JOB202112145350200，要传输的原始数据文件为GF01_01_046541_20211214_KS1J1_R0.dat和GF01_02_046541_20211214_KS1J2_R0.dat。

1、根据遥感卫星原始数据（记为x.dat）中数据头信息、辅助信息、原始数据三部分，分解成两部分，第一部分包含数据头信息、辅助信息，定义为4M头部数据，记为x.4M，第二部分包含原始数据，定义为裸数据部分，记为x.raw。x.4M+x.raw＝x.dat的原则，将GF01_01_046541_20211214_KS1J1_R0.dat分为：

GF01_01_046541_20211214_KS1J1_R0.raw；

GF01_01_046541_20211214_KS1J1_R0.4M。

将GF01_02_046541_20211214_KS1J2_R0.dat分为：

GF01_02_046541_20211214_KS1J2_R0.raw；

GF01_02_046541_20211214_KS1J2_R0.4M。

2、在遥感卫星原始数据实时记录开始时，先在目标FTP目录下创建一个子文件目录JOB202112145350200，再在该目录下创建任务描述文件JOB202112145350200.DESC，以描述本次任务应当传输的文件列表

GF01_01_046541_20211214_KS1J1_R0.raw，

GF01_01_046541_20211214_KS1J1_R0.4M，

GF01_02_046541_20211214_KS1J2_R0.raw，

GF01_02_046541_20211214_KS1J2_R0.4M。

在记录过程中，边记录边开始以FTP协议实时传输接收到的GF01_01_046541_20211214_KS1J1_R0.raw；

和GF01_02_046541_20211214_KS1J2_R0.raw数据到相应的FTP服务器目录下，在记录完成后，再传输：

GF01_01_046541_20211214_KS1J1_R0.4M头部数据；

GF01_02_046541_20211214_KS1J2_R0.4M头部数据。

所有文件传输完成之后，则在目标FTP子目录JOB202112145350200下创建一个传输结束文件，该文件内容为空，文件名为：JOB202112145350200.OK。

3、服务器端程序检索到JOB202112145350200.OK文件之后；

将GF01_01_046541_20211214_KS1J1_R0.4M；

GF01_01_046541_20211214_KS1J1_R0.raw文件拼接合成为：

GF01_01_046541_20211214_KS1J1_R0.dat文件。

将GF01_02_046541_20211214_KS1J2_R0.4M：

GF01_01_046541_20211214_KS1J2_R0.raw文件拼接合成为：

GF01_02_046541_20211214_KS1J2_R0.dat文件，形成符合国家推荐标准格式的原始数据。至此，从数据记录系统到下游系统的实时传输任务完成了。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (5)

1.一种采用FTP协议实时传输遥感卫星原始数据的方法，其特征在于，采用FTP协议代替采用自定义的实时传输协议，实时传输符合国家推荐标准的遥感卫星原始数据，在发送端部署FTP客户端程序，在接收端部署FTP服务器程序并进行FTP服务器相应设置，其中，所述国家推荐标准为《遥感卫星原始数据记录与交换格式》，标准号为GB/T 31011-2014，所述方法包括：

客户端将遥感卫星原始数据分解为第一信息数据和第二信息数据；其中所述第一信息数据包括数据头信息和辅助信息，所述第二信息数据包括原始数据信息；

客户端向FTP服务器发送创建请求，所述FTP服务器接收到客户端发送的创建请求之后，创建表示传输任务的子文件目录，并在所述子文件目录下创建与所述传输任务对应的任务描述文件以描述本次任务应当传输的文件列表；

客户端通过FTP协议先后向FTP服务器发送所述传输任务对应的描述文件、第二信息数据和第一信息数据文件以及传输结束标示文件；

FTP服务器接收到以上文件之后，基于第一信息数据和第二信息数据合成遥感卫星原始数据文件，完成遥感卫星原始数据的实时传输。

2.根据权利要求1所述的一种采用FTP协议实时传输遥感卫星原始数据的方法，其特征在于，所述客户端将遥感卫星原始数据分解为第一信息数据和第二信息数据，具体包括：

客户端将遥感卫星原始数据分解为多个第一信息数据和多个第二信息数据；

所述基于第一信息数据和第二信息数据合成遥感卫星原始数据文件，具体包括：

基于多个第一信息数据和多个第二信息数据合成遥感卫星原始数据文件。

3.根据权利要求1所述的一种采用FTP协议实时传输遥感卫星原始数据的方法，其特征在于，所述客户端通过FTP协议先后向FTP服务器发送所述传输任务对应的描述文件、第二信息数据和第一信息数据文件以及传输结束标示文件，具体包括：

客户端通过FTP协议向FTP服务器发送所述传输任务对应的描述文件和传输结束标示文件，以及先后发送多个第二信息数据和多个第一信息数据文件。

4.根据权利要求3所述的一种采用FTP协议实时传输遥感卫星原始数据的方法，其特征在于， 所述方法还包括：存在逐个环节依次进行遥感卫星原始数据实时传输的情况下，每个环节的客户端同时通过FTP协议向每个环节的FTP 服务器传输第二信息数据；

每个FTP服务器接收客户端传输的所有第二信息数据之后，每个客户端再向所述FTP服务器补传遥感卫星原始数据的第一信息数据，FTP 服务器结合第二信息数据合成遥感卫星原始数据文件。

5.根据权利要求1所述的一种采用FTP协议实时传输遥感卫星原始数据的方法，其特征在于，存在多台FTP服务器的情况下，所述方法还包括：

利用FTP协议的被动模式结合LVS，通过虚拟IP地址，实现对多台FTP服务器传输的负载均衡功能。

Images