CN102739644B - 一种金融数据的发送/接收方法及装置 - Google Patents

Abstract

本发明涉及一种发送金融数据的方法，包括如下步骤：分别取得将发送所述数据的源端地址和目的端地址；产生数据包的唯一识别码；按设定格式组成数据包，并将所述源端地址、目的端地址以及唯一识别码按照设定顺序放入所述数据包；发送所述数据包到与源端连接的交换中心。本发明还涉及一种接收金融数据的方法、金融数据发送装置和接收装置。实施本发明的发送/接收金融数据的方法及装置，具有以下有益效果：其数据传输的效率较高、花费时间短、较易普及。

Description

一种金融数据的发送/接收方法及装置

技术领域

本发明涉及数据传输，更具体地说，涉及一种金融数据的发送/接收方法及装置。

背景技术

金融市场的发展，使银行、证券、保险、期货、基金等各金融行业及其之间业务交互（即数据交换）的需求不断扩大，而计算机和网络技术的进步，使这些业务交互越来越趋于电子化。尽管在国际上早就有SWIFT（环球银行电信协会）等组织提供金融数据交换服务，但是由于SWIFT包含太多标准（240种），应用到具体机构的业务系统中时，显得臃肿冗余，且主要应用于国际上的一些大的金融体。在国内，虽然也有银联这样的成功案例，但全国性金融机构间的数据交互系统在中国金融业依然是一片空白。此外，虽然上海证券通信有限公司的Prop数据交换系统是为证券市场参与人之间提供数据交换服务的一个系统，但该系统采用传统的C/S一应一答模式，其传输效率不高；且现有的金融数据交换技术均基于某个特定金融机构内部的数据交换，只能满足单一用户对其它用户的通信要求而没有一个综合性强的，各个机构间网状通信的多对多消息交换系统。由于银证转账、银证通、开放式基金、第三方存管业务的相继推出，促进了证券市场的快速发展，相关业务已不再仅仅局限于证券业内部，而是越发紧密地与银行、保险等其他金融行业联系在一起，并且同一个机构往往同时需要与其它多家机构进行消息交换。这对于金融行业各机构间（特别是涉及金融数据传输的行业间）数据通信的准确性、及时性及安全性提出了更高的要求。

发明内容

本发明要解决的技术问题在于，针对现有技术的上述数据传输效率不高、花费时间长、不易普及缺陷，提供一种数据传输效率较高、花费时间较短、易于普及的一种金融数据的发送/接收方法及装置。

本发明解决其技术问题所采用的技术方案是：构造一种发送金融数据的方法，包括如下步骤：

A)分别取得将发送所述数据的源端地址和目的端地址；其中，所述源端地址包括所述源端的用户标识和产生所述数据的源应用标识，所述目的端地址包括接收所述数据的目的端用户标识和使用所述数据的目的应用标识；源应用是在源端上运行的应用程序，目的应用是在目的端上运行的应用程序；

B)产生数据包的唯一识别码；

C)按设定格式将数据组成数据包，并将所述源端地址、目的端地址以及唯一识别码按照设定顺序放入所述数据包；

D）发送所述数据包到与源端连接的交换中心。

在本发明所述的发送金融数据的方法中，所述步骤B）中还包括取得向所述源应用要求所述数据的数据包的整个系统全局唯一识别码，并设置为相关包识别码；所述步骤C）中还包括将所述相关包识别码按设定位置放入所述产生的数据包。

在本发明所述的发送金融数据的方法中，所述步骤C）中还包括在组成所述数据包前，对其包括的数据进行加密，并对加密后的数据进行压缩处理。

在本发明所述的发送金融数据的方法中，所述源端地址、目的端地址、唯一识别码、相关识别码依次排列在所述数据包中；所述源端用户标识和源应用标识依次排列在所述源端地址中；所述目的端用户标识和目的端应用标识依次排列在所述目的端地址中。

本发明还涉及一种接收上述方法发送来的金融数据的方法，包括如下步骤：

M）取得所述数据包并取出其目的端地址；所述目的端地址包括依次排列的目的端用户标识和目的端应用标识；

N）查找所述目的端用户标识和目的端应用标识对应的端口；

O）直接发送所述数据包到所述端口；

P）解开数据包并将所述数据传输给所述目的应用，所述目的应用是运行在目的端的应用程序。

在本发明所述的接收金融数据的方法中，所述步骤P）中还包括对所述数据包包括的数据解压缩并解密。

在本发明所述的接收金融数据的方法中，所述步骤P）中还包括取得所述相关包识别码，如请求中要求反馈，则产生反馈包并输出。

本发明还涉及一种实现上述发送金融数据方法的装置，包括：

地址取得单元：用于分别取得将发送所述数据的源端地址和目的端地址；其中，所述源端地址包括所述源端的用户标识和产生所述数据的源应用标识，所述目的端地址包括接收所述数据的目的端用户标识和使用所述数据的目的应用标识；源应用是在源端上运行的应用程序，目的应用是在目的端上运行的应用程序；

整个系统全局唯一识别码产生单元：用于产生数据包的唯一识别码；

数据包形成单元：用于按设定格式将数据组成数据包，并将所述源端地址、目的端地址以及唯一识别码按照设定顺序放入所述数据包；

数据包发送单元：用于发送所述数据包到与源端连接的交换中心。

在本发明所述的实现上述发送金融数据方法的装置中，还包括：

数据加密和压缩处理单元：用于对放入数据包的数据进行加密，并对加密后的数据进行压缩处理；

相关包识别码取得单元：用于取得要求数据的数据包的唯一识别码，并设置为本数据包的相关包识别码。

本发明还涉及一种实现上述接收金融数据方法的装置，，包括：

目的地址取得单元：用于取得所述数据包并取出其目的端地址；所述目的端地址包括依次排列的目的端用户标识和目的端应用标识；

目的端口取得单元：用于查找所述目的端用户标识和目的端应用标识对应的端口；

转发单元：用于直接发送所述数据包到所述端口；

数据包解压和解密单元：用于解开数据包并将所述数据传输给所述目的应用，所述目的应用是运行在目的端的应用程序；

数据反馈标记产生单元：用于取得所述相关包识别码，并产生反馈包。

实施本发明的发送/接收金融数据的方法及装置，具有以下有益效果：由于将源地址和目的地址分解为源端标识和源端应用标识，将目的地址分解为目的标识和目的应用标识，使得数据在传输过程中，具体来讲是在连接上述源端和目的端的数据交换中心可以直接地找到该数据包对应的数据端口，从而可以直接地在交换中心将数据包直接通过该端口传输到目的端，不需要在大量的应用或客户端之间重复传输数据或广播，减少数据包传输到目的端后再次判断该数据的目的应用的时间；所以其数据传输的效率较高、花费时间短；同时由于采用TCP协议传输数据，故其较易普及。

附图说明

图1是本发明发送/接收金融数据的方法及装置实施例中金融数据的发送方法流程图；

图2是所述实施例中金融数据的接收方法流程图；

图3是所述实施例中金融数据发送装置结构示意图；

图4是所述实施例中金融数据接收装置结构示意图；

图5是所述实施例中通过API接口发送和接收一个消息的过程示意图。

具体实施方式

下面将结合附图对本发明实施例作进一步说明。

如图1所示，在本发明的发送/接收金融数据的方法及装置实施例中实施例中，金融数据的发送包括如下步骤：

步骤S11取得源端用户标记和源端应用标记，得到源端地址：在本实施例中，其网络的结构是多个用户端通过交换中心连接在一起，这些连接在一起的多个用户端可以是对等的（例如可以都是客户端），也可以不是对等的（例如其中一些可以是服务器，而另外一些是客户端）；同时，这里的交换中心也可能不仅仅是传统意义上的交换中心，还可以是带有路由功能的交换中心，这需要视网络的具体情况而定。而不管上述任何一种情况，本实施例中所记载的方法都可以应用。具体而言，一个数据的产生，不管其产生的原因是应别的用户端的请求也好，是自己产生的也好，其一定是由一个客户端上的应用程序产生的，而不可能是凭空出现的。在本实施例中，事先将每个客户端都以一个设定的标识来表示，而运行在每个客户端上的每个应用程序，也是以不同的标识来表示的。对于客户端（用户标识）和应用程序（应用标识）而言，其标识都是不同的；同时，这些标记在被用户确定后，客户端都会通知与其连接的交换中心，使得该交换中心能够得知这些标识所代表的意义及其相关参数。在本步骤中，就是按照数据产生的源，取得产生该数据的源端的用户标记和产生该数据的在该客户端上运行的应用程序的源端应用标记；值得一提的是，在取得这两个标记后，将其按照源端用户标记和源端应用标记的顺序排列，得到源端地址，换句话说，源端地址由源端用户标记和源端应用标记两者共同组成。

步骤S12取得目的端用户标记和目的端应用标记，得到目的端地址：数据产生后，需要发送到指定的位置，交给指定的应用程序；当数据是在别的客户端要求的情况下产生的和在本客户端的某些条件满足后触发而产生的，这些目的端的标记和目的应用标识都是已知的。在本步骤中，取得数据将要发送到位置的目的端用户标记和目的端应用标记，并将其按照目的端用户标记和目的端应用标记的顺序排列，得到目的端地址。

步骤S13产生数据包唯一识别码，并取得相关数据包识别码：在本实施例中，应用程序产生的数据都是通过数据包的形式发送出去的，在发送之前，需要将数据转换或打包成为设定格式的数据包；底层使用TCP协议来发送数据包，但是在本系统中有自己定义的应用层的源或目标地址标识符。本实施例中，在数据包中除了包括标准的TCP协议包头应该据有的部分之外，还包括一个表示该数据包身份的唯一识别码；这个唯一识别码与该数据包对应，每个数据包都具有唯一的、不重复的识别码，这个识别码也将被放入数据包头中。在本步骤中，就是产生并取得该数据包的唯一识别码；同时，在本步骤中，如果该数据包是由于另外一个来自其他客户端或本客户端的数据包的请求而产生的，运行在客户端上的应用程序是知道该要求数据的数据包的唯一识别码，这是由于要求数据的数据包将传输到该应用程序，而其包头中是存在其唯一识别码的；应用程序只要取出要求数据的数据包头中指定位置的数据就是该数据包的唯一识别码；在本步骤中，还取得该要求数据的数据包的唯一识别码，并将该唯一识别码作为即将发出的、传送被要求数据的数据包的相关数据包识别码，该相关数据包识别码也将被放入上述传送被要求数据的数据包的包头设定位置。这样做的好处是，当被要求传输的数据发送到目的客户端或应用程序时，目的客户端或应用程序只要读出该相关数据包识别码，就能够得知这些数据是对应哪个原请求包要求的，提高了对得到数据管理的效率。

步骤S14加密、压缩数据并将上述加密、压缩后的数据与上述地址、识别码等按照设定格式处理得到数据包：在本实施例中，在取得上述各地址、识别码之后，对将要传输的、由上述应用程序产生的数据进行加密处理、压缩处理之后，将上述加密、压缩处理后的数据作为数据包的数据，而将上述取得的各地址、识别码按照事先设定的顺序放入数据包头，按照设定的格式将上述数据和地址、识别码进行打包而得到将要发送的数据包；在其他一些情况下，上述加密、压缩处理的动作也可以是和上述取得各地址、识别码的动作同步进行，而在本步骤将其合在一起，按照设定格式处理进而得到数据包。在本步骤中，得到的数据包是TCP协议之上的应用层数据包，在本系统中有自己定义的应用层的源或目标地址标识符。此外，在上述源地址和目的地址之后，还排列有该数据包的唯一识别码和该数据包的相关识别码。

步骤S15发送得到的数据包到交换中心：在本步骤中，客户端将上述步骤中得到的数据包发送到与该客户端连接的交换中心，由该交换中心发送到目的端去。

请参见图2，当上述数据发送到与源端连接的交换中心后，在交换中心及与交换中心连接的目的端将有如下步骤：

步骤S21取得数据包并取出目的地址：在本实施例中，数据包的接收包括了从交换中心或目的客户端（也可以包括客户端或服务器，但都是数据传输的目的端）进行接收两者方式。总体来讲，在对数据包进行加密、压缩是在源端实现的，而数据包的解压、解密及其之后的步骤，都是在目的端上实现的。但是，上面的描述只是一个基本的划分，在一些情况下，上述的划分也可能不是一定的。这需要视具体情况而定。在本步骤中，取出数据包中的目的地址，这里的取出仅仅只是解开包头并在指定位置读取出其内容，就能得到上述数据包的目的地址，在此同时，并不会解开整个数据包，数据包中的数据仍然未被读取，还是保持传输来的状态。这种操作的好处是可以较大地节省时间及开销。

步骤S22按照目的地址中的目的端用户标识和目的端应用标识查找对应的端口：在本步骤中，当取得上述数据包中的目的地址之后，由该目的地址中将其中的目的用户标识和目的应用标识取出，然后查找该目的用户标识和目的应用标识对应的通信端口；由于一个目的用户标识可能会对应多个通信端口，所以需要目的应用标识才能确定该数据包需要传输到的具体的通信端口；这是由于一个用户（客户端或服务器）端上可能有多个应用程序在运行，而依据TCP协议的规定，这些不同的应用程序即使在同一个用户标识下，其使用的也是不同的通信端口；如果不能确定具体的通信端口，当数据包传输到该用户标识所指示的客户端时，还需要进一步地判断将该数据给哪个应用程序；而在本实施例中，直接在交换中心判断出其具体的通信端口，就可以直接将数据包通过该端口传输到应用程序，进而节省在目的端的判断步骤和时间，使得在同等条件下，可以降低对目的端的配置。在本实施例中，上述各客户端的应用程序在运行时都会在通过其使用的通信端口通知上述交换中心，这样，在交换中心上就存在一个记录了各客户端上的应用程序使用的通信端口的清单，在本步骤中，就是通过查找该清单得到该目的端用户标记及应用标记对应的通信端口。

步骤S23发送该数据包到找到的端口：在本步骤中，将上述接收到的数据包发送到该查找到的端口，并通过该端口将数据包传输到目的端。

步骤S24取得数据包中的相关包识别码，产生反馈包并输出：在目的端，取得上述数据包中的识别码，并产生一个反馈信号，具体为一个反馈数据包，表示之前的某个数据请求已经被目的端收到，并将该反馈包输出到发出请求的客户端。在一些情况下，根据配置选项，也可以根据需要不产生反馈包。

步骤S25解密、解压该数据包并将得到的数据传输到指定应用中：在本步骤中，按照数据包形成时的条件，对上述接收到的数据包进行解密、解压缩，得到数据，并将数据传输到使用该数据的、由上述应用标记表示的应用程序中。

在本实施例中，还涉及分别实现上述金融数据发送方法的装置和实现上述金融数据发送方法的装置。如图3所示，实现上述金融数据发送方法的装置包括：地址取得单元31、唯一识别码产生单元32、数据包形成单元33、数据包发送单元34、数据压缩处理单元35和相关包识别码取得单元36；其中，地址取得单元31用于分别取得发送数据的源端地址和目的端地址；而源端地址包括源端的用户标识和产生上述数据的源应用标识，目的端地址包括接收上述数据的目的端用户标识和使用上述数据的目的应用标识；源应用是在源端上运行的应用程序，目的应用是在目的端上运行的应用程序；唯一识别码产生单元32用于产生上述数据所形成数据包的唯一识别码；数据包形成单元33用于按设定格式产生数据包，并将上述源端地址、目的端地址以及唯一识别码按照设定顺序放入所述数据包；在本实施例中，产生的数据包通过TCP协议来传输；数据包发送单元34用于发送上述数据包到与源端连接的交换中心；数据压缩处理单元35用于对还没有放入数据包的数据进行压缩，并对压缩后的数据进行加密处理；当上述处理完成后，处理后的数据才能放入数据包；相关包识别码取得单元36用于取得要求数据的数据包的唯一识别码，并设置为本数据包的相关包识别码。

图4示出了本实施例中的实现上述金融数据接收方法的装置，包括：目的地址取得单元41、目的端口取得单元42、转发单元43、数据包解压单元44和数据返回标记产生单元45；其中，目的地址取得单元41用于取得所述数据包并取出其目的端地址；所述目的端地址包括依次排列的目的端用户标识和目的端应用标识；目的端口取得单元42用于查找所述目的端用户标识和目的端应用标识对应的端口；转发单元43用于直接发送所述数据包到所述端口；数据包解压单元44用于解开数据包并将所述数据传输给所述目的应用，所述目的应用是运行在目的端的应用程序；数据返回标记产生单元45用于取得所述相关包识别码，并产生表示该数据包要求数据已返回数据的标记给产生所述要求数据的目的应用。

在本实施例中，上述金融数据的发送和接收方法都是通过计算机软件实现的，而上述发送装置和接收装置分别是实现其方法的软件功能模块；在实际的使用中，这些功能模块可以在同一个物理载体上，也可以不在同一个物理载体上。就本实施例中的情况而言，将上述发送方法和接收方法封装在一起，得到一个用于金融数据交换平台的API接口（FDEAPI），该接口可以设置在交换中心，也可以设置在各客户端；设置在不同位置的接口配合，即可在每个连接在交换中心上的客户端实现上述金融数据的发送和接收。下面以一个消息为例，具体说明其产生及接收过程。

API接口（FDEAPI）是基于FDEP为金融行业提供业务数据交换服务的，其为供给用户调用的C语言的应用程序编程接口，调用该API开发，通过接入客户端（MR）接入平台进行数据交换。业务处理系统调用该API接口与其他用户进行数据交换，其主要的基本功能包括发送消息和接收消息。发送消息时，调用API相应的发送接口函数发送业务数据，该接口实现将用户业务数据进行压缩和加密，并根据自定义的消息包协议组包，再发送数据出去。接收消息时，调用API相应的接收接口函数接收业务数据，该接口将收到的业务数据进行解压缩和解密，并根据自定义的消息包协议解包，取出数据内容。API采用自定义的消息包协议结构如下所示：

structSTUMsgProperty

{

charm_szSourceUserID[MR_MAXLEN_ADDR];//源用户标识

charm_szSourceAppID[MR_MAXLEN_ADDR];//源应用标识

charm_szDestUserID[MR_MAXLEN_ADDR];//目的用户标识

charm_szDestAppID[MR_MAXLEN_ADDR];//目的应用标识

charm_szPkgID[MR_MAXLEN_PKGID];//数据包的包标识

charm_szCorrPkgID[MR_MAXLEN_PKGID];//相关包标识

charm_szUserData1[MR_MAXLEN_USERDATA];//用户数据1

charm_szUserData2[MR_MAXLEN_USERDATA];//用户数据2

charm_szExpiredAbsTime[MR_MAXLEN_EXPIREDABSTIME];//该消息的过期时间，格式为“YYYY-MM-DDHH:MM:SS”

unsignedcharm_ucFlag;//消息压缩等标志

unsignedcharm_ucProtocolType;//协议类型

}

其中，源用户标识和源应用标识共同表示源端用户的地址，目的用户标识和目的应用标识共同表示目的端的用户地址。为了区分同一个业务（或应用）的不同数据包，数据包ID标记了全局唯一的业务消息包，对不同的数据根据数据包ID进行不同的处理。相关包ID（m_szCorrPkgID）是用户调用发送接口函数发送业务应答包时，供用户填写的与对应业务请求包中消息包ID（m_szPkgID）相同的值，以方便请求方接收到应答包后，根据该相关包ID字段查找对应的请求包。m_szUserData1和m_szUserData2是供用户填充和使用的附加数据。该结构简洁地表示了一个消息包的源端用户地址、目的端用户地址、数据包的全局唯一ID、相关包ID、用户附加数据、消息的过期时间、是否压缩标志和消息协议的类型。API接口能够解析出一个消息包的所有字段，并进行相应的处理。

在上述处理过程中，采用zlib库中的压缩算法对用户的业务数据进行压缩，该算法使用很少的系统资源，速度快，对各种数据提供很好的压缩效果。并且在Windows系统和Linux系统中都能使用。加解密是采用RC6算法对用户的业务数据进行加解密处理，该算法是作为AES的一种新的分组密码，具有高性能和高安全性

每个用户有一个唯一的用户标识（UserID），用户标识由不超过63个字符组成，字符可以是大写字母、小写字母、数字、减号或下划线，首字符必须是字母。一个用户标识即对应一个接入客户端。一个接入客户端可以支持多个业务应用接入FDEP。为了区分不用的应用，每个应用使用一个唯一的应用标识（AppID），应用标识的命名规则和用户标识相同。

消息（数据）是由具体的应用发出的，最终也要由具体的应用接收并处理。例如银行作为一个用户，第三方存管业务就是其中一个应用，银期转账和信托等业务都是银行这一用户下的应用，不同的银行具有不同的用户标识。

因此，数据的源地址和目的地址都要用用户标识和应用标识两个要素共同表示。消息（或数据）有四个必需的地址要素：源用户标识、源应用标识、目的用户标识、目的应用标识。

用户安装好接入客户端程序后，开发自己的业务系统调用FDEAPI接口与接入客户端进行TCP通信，为业务收发消息（数据）。接入客户端与交换中枢进行SSL连接通信，接入客户端收到消息后，转发到交换中枢，由中枢发送到目的客户端，SSL通信是为了对数据进行加密传输，确保数据的安全性。接入客户端可以有多个，从而实现接入客户端的负载均衡。交换中枢运行在高性能的PC服务器上，主要功能是转发各个用户发送上来的消息包到目的客户端，交换中枢存在多个交换单元，且两两建立全连接（TCP），实现了冗余备份和负载均衡。请参见图5，图5中具体描述了用户通过上述API接口发送和接收一个消息的过程。在图5中，包括两个部分，一个部分沿由左到右的箭头，为由数据转换为符合要求的数据包并发送的过程；另一部分沿由右到左的箭头，为接收数据包并将其转换为数据的过程；每个部分都标明了需要经过的步骤及步骤的内容，与上述数据发送和接收的步骤相似，在此不在赘述。

FDEAPI可以完成通信的自动连接、发送消息包、接收消息包、加密压缩等功能，应用程序可以用FDEAPI与金融数据交换平台的接入客户端实现交互。FDEAPI提供了如下12个函数供用户操作：

序号	函数名称	函数功能
			1	MrInit	初始化，获取相关资源，并尝试与接入客户端建立连接。
2	MrInit2	初始化，获取相关资源，并尝试与接入客户端建立连接（多线程方式回调）。
			3	MrIsLinkOK	查看并判断当前与接入客户端的连接是否正常。
4	MrCreatePkgID	生成数据包全局唯一标识。
			5	MrSend	通过接入客户端向消息中枢发送消息，请求转发。
6	MrReceive1	以方式1接收消息中枢转发来的消息。
			7	MrReceive1_FreeBuf	释放MrReceive1函数调用中分配的内存。
8	MrBrowse	查看本用户的下一个可接收数据包。
			9	MrReceive2	以方式2接收消息中枢转发来的消息。
10	MrReceive3	以方式3接收消息中枢转发来的消息。
			11	MrDestroy	断开与接入客户端的连接，释放相关资源。
12	MrGetVersion	获取该API的版本号。
			13	MrRegRecvCodition	指定接收条件由接入客户端推送数据。

其中，接收方式1、接收方式2和接收方式3都可以接收正常的消息数据，而方式3可以接收系统错误消息，会返回错误码和错误的原因字符串；方式1和方式2的区别在于消息接收缓冲区分配和内存管理不同，方式2需要用户自己分配和管理，方式1不需要。MrBrowse接口函数可查看下一个可接收消息包的消息属性，供用户处理特定需求的包；MrRegRecvCodition接口函数可供用户向接入客户端注册接收条件，从而接入客户端可以自动推送满足接收条件的数据至用户的业务系统，比已有的技术提高了效率，同时也兼容旧的一应一答模式。

以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。

Claims (7)

1.一种发送金融数据的方法，其特征在于，包括如下步骤：

A)分别取得将发送所述数据的源端地址和目的端地址；其中，所述源端地址包括所述源端的用户标识和产生所述数据的源应用标识，所述目的端地址包括接收所述数据的目的端用户标识和使用所述数据的目的应用标识；所述目的端用户标识和所述目的应用标识是在数据产生时已知的；源应用是在源端上运行的应用程序，目的应用是在目的端上运行的应用程序；所述源端和所述目的端通过交换中心连接；

B)产生数据包的唯一识别码；

C)按设定格式将数据组成数据包，并将所述源端地址、目的端地址以及唯一识别码按照设定顺序放入所述数据包；

D）发送所述数据包到与源端连接的交换中心；

其中，在上述产生的数据包是在其他客户端或本客户端的数据包的要求而产生时，所述步骤B）中还包括取得向所述源应用要求所述数据的数据包的唯一识别码，并设置为相关包识别码，所述步骤C）中还包括将所述相关包识别码按设定位置放入所述产生的数据包。

2.根据权利要求1所述的发送金融数据的方法，其特征在于，所述步骤C）中还包括在组成所述数据包前，对其包括的数据进行加密，并对加密后的数据进行压缩处理。

3.根据权利要求2所述的发送金融数据的方法，其特征在于，所述源端地址、目的端地址、唯一识别码、相关包识别码依次排列在所述数据包中；所述源端用户标识和源应用标识依次排列在所述源端地址中；所述目的端用户标识和目的端应用标识依次排列在所述目的端地址中。

4.一种如权利要求1所述方法发送的金融数据的接收方法，其特征在于，包括如下步骤：

M）取得所述数据包并取出其目的端地址；所述目的端地址包括依次排列的目的端用户标识和目的端应用标识；

N）查找所述目的端用户标识和目的端应用标识对应的端口；

O）直接发送所述数据包到所述端口；

P）解开数据包并将所述数据传输给所述目的应用，所述目的应用是运行在目的端的应用程序；

其中，所述步骤P）中还包括取得相关包识别码，并产生反馈包输出到发出请求的客户端。

5.根据权利要求4所述的金融数据接收方法，其特征在于，所述步骤P）中还包括对所述数据包包括的数据解压缩并解密。

6.一种金融数据的发送装置，其特征在于，包括：

地址取得单元：用于分别取得将发送所述数据的源端地址和目的端地址；其中，所述源端地址包括所述源端的用户标识和产生所述数据的源应用标识，所述目的端地址包括接收所述数据的目的端用户标识和使用所述数据的目的应用标识；所述目的端用户标识和所述目的应用标识是在数据产生时已知的；源应用是在源端上运行的应用程序，目的应用是在目的端上运行的应用程序；所述源端和所述目的端通过交换中心连接；

唯一识别码产生单元：用于产生数据包的唯一识别码；

数据包形成单元：用于按设定格式将数据数据包，并将所述源端地址、目的端地址以及唯一识别码按照设定顺序放入所述数据包；

数据包发送单元：用于发送所述数据包到与源端连接的交换中心；

数据加密压缩处理单元：用于对放入数据包的数据进行加密，并对加密后的数据进行压缩处理；

其中，在上述产生的数据包是在其他客户端或本客户端的数据包的要求而产生时，还包括：

相关包识别码取得单元：用于取得要求数据的数据包的唯一识别码，并设置为本数据包的相关包识别码。

7.一种金融数据接收装置，其特征在于，包括：

目的地址取得单元：用于取得所述数据包并取出其目的端地址；所述目的端地址包括依次排列的目的端用户标识和目的端应用标识；

目的端口取得单元：用于查找所述目的端用户标识和目的端应用标识对应的端口；

转发单元：用于直接发送所述数据包到所述端口；

数据包解密和解压单元：用于解开数据包并将所述数据传输给所述目的应用，所述目的应用是运行在目的端的应用程序；

数据反馈标记产生单元：用于取得相关包识别码，并产生反馈包输出到发出请求的客户端。