CN102158847A - 手机与服务器之间的通讯方法及*** - Google Patents

Abstract

本申请涉及一种手机与服务器之间的通讯方法及***，该方法包括如下步骤：(1)服务器接收手机发送的请求一文件的数据请求；(2)根据该数据请求，服务器以文件块的形式向手机发送所请求的文件，并将发送的文件块的位置实时记录在缓存设备中；以及(3)当手机与服务器的连接断开后，服务器在接收到手机重发的数据请求时，根据该缓存设备中记录的文件块的位置进行后续文件块的传送。本申请的手机与服务器之间的通讯方法及***可使通信更加安全、高效。

Description

手机与服务器之间的通讯方法及***

技术领域

本发明涉及一种通讯技术，特别涉及一种手机与服务器之间的通讯方法及***。

背景技术

随着手机移动网络的迅猛发展，首当其冲的就是被誉为手机杀手锏应用的手机音乐服务，这项应用服务不仅拓展了手机的功能，更是极大地推动着手机硬件以及移动网络的发展，让手机不再单单只是播放手机上已经存在的歌曲资源，而是能够通过移动互联网络让手机与服务器通讯成为了现实。通过手机音乐服务将手机与网络互动的作用更加地放大和扩充，使得手机不再单单是打电话或发短信的工具，而是真正意义上的移动音乐终端，可将更丰富的网络音乐素材资源源源不断地下载或推送到手机上。

一种客户端设备与服务端设备的通信采用如下通讯指令步骤完成交互传输，其可以归纳抽象描述为：conn(连接)-＞user(用户验证)-＞pass(密码安全握手)-＞init(初始化数据)-＞list(列表)-＞items(资源元素)-＞download(下载)或者play(播放)；还包括back(返回)指令和exit(退出)指令，其中back指令为返回请求前一指令的指令，其可在conn指令后任意一个指令(user，pass，init，list，items，download，play)操作后进行请求，exit指令为通知服务端设备退出客户端设备软件***的指令，其位置顺序与back指令相同；并且，list指令所请求数据为树型结构，若返回的数据里某叶子节点数据为列表结构，即可重复请求list指令对叶子节点的数据进行请求。

采用一种单向静态安全登录校验模型(single-track static authenticationmodule，SSM)作为客户端设备与服务器通讯过程中进行用户验证的方式。参考图1，其示出了单向静态安全登录校验模型的时序图。在客户端设备发送登录指令user后，一般客户端设备还需要发送密码校验命令pass，这样能够让服务端设备进行安全校验。当安全校验通过后服务端设备才能知道此客户端设备的请求是否属于合法的请求，进而才可以进行后续的命令字操作。这种安全模型对于大多数客户端设备来说足以，但是对于采用了某些计费手段的客户端设备来说，这种方式就会有一定的局限性，这是因为只进行一次安全校验握手，而且这种安全校验握手是单向的行为，因而会导致某些非法程序非法侵入或是模拟指令发送以至于服务端设备对这种信息完全没有任何的判断能力，从而使得安全性很差。

此外，在客户端设备与服务端设备的通讯过程中使用一种客户端多线程模型(Mobile client multithreading module，MTM)。在该客户端多线程模型中，在客户端设备需要批量下载音乐素材资源或是播放歌曲的时候，采用的办法是在某些中高端手机能够支持的模式下，在客户端设备采取多线程的技术同时向服务器请求素材文件数据资源，并将素材文件数据资源同步下载到客户端设备上，其大致时序图如图2所示。可以看出，这种模型理论上看很不错，几乎可以认为同一时间段内，数据是并发请求到服务端设备，而服务端设备也可以并发进行响应，将数据同一时间段内推送到客户端设备。但是，手机硬件资源往往有限，特别是中低端手机，多线程技术一般不会被采用，如果采用那也将会极大地消耗硬件资源，使其损耗变大、寿命变短，且容易发生“死机”(宕机)现象；另外，即使是较高端的手机，依旧受限于手机处理器芯片的处理能力，在很小的时间片内仍然是时间线性执行的，而另一个因素是虽然客户端设备采取了多线程处理机制，但是服务端设备却只开启了单线程进行数据通信，那么这样两者结合来看处理数据资源时并不能真正达到“同时”的效果，这样会导致偏向单个素材资源的处理过程，而其它资源却一直需要等待。

另外，使用一种客户端缓存模型(Mobile client cache module，CCM)来加速客户端设备的执行效率，因为大多数客户端设备会采用一种手机客户端缓存数据的技术，将历史请求的命令得到的服务器返回数据暂存在手机内存中，以便于在有同样请求时可以减少对远程服务器访问的开销，这项技术的关键之处是客户端设备认为服务端设备在数据执行中查找磁盘I/O所造成的开销较大而希望尽量减少这种远程请求，当然，这种行为只会在初始化之后进行，初始化前还是需要与服务端设备进行安全登录校验的，其大致流程如图3所示。但是，由于服务端设备不保留历史数据以及某个客户端设备连接的状态，故在出现网络故障时客户端设备与服务器断开连接后，客户端设备必须通过重新连接并初始化后才能进行后续的操作，而且这些后续操作与断开前的操作完全没有连续性，因而使得操作效率降低，并给用户带来不便利性。而且，如果手机关机重启，则暂时缓存在手机内存中的历史数据一并消失，客户端设备将无法重置成上一次使用时候需要维持的任何状态。

综上所述，在前述客户端设备与服务端设备的通讯中，无论是基于HTTP协议的扩展还是更基础的tcp/ip方式，都只是让客户端设备与服务端设备做简单的握手校验，并且在客户端设备采取多线程技术让手机可同时处理请求多个音乐素材资源的事务，这样可以保障一定的数据安全性和一定的可靠性，主要提供了以下的一些技术特性：

(1)客户端设备与服务端设备只在初始化之前校验一次来源通道的合法性，然后建立长连接，之后的数据在客户端设备传递到服务端设备时不再做数据加密处理；

(2)客户端设备采用多线程技术可批量处理多个任务，如批量下载音乐素材资源等；

(3)通讯过程中发生网络故障后可以自动尝试重新连接，所以客户端设备可重新进行连接来初始化或重新定位需要下载的资源文件；

(4)历史数据操作被缓存在手机的内存中，在手机不关机重启的情况下可以加速客户端设备的运行效率。

如上所述，可以看出上述客户端设备与服务端设备的通讯技术存在如下几个问题：

(1)由于安全登录校验只使用一次安全校验握手，因而难以很好地确保通讯的安全性；

(2)由于在客户端设备使用多线程技术，导致客户端设备损耗变大、寿命变短、速度慢，而且使得客户端设备与服务器之间的通讯效率变低；

(3)由于服务端设备不保留历史数据以及客户端设备连接的状态，因而在出现网络故障时服务端设备与客户端设备断开后客户端设备必须通过重新连接并初始化后才能进行后续的操作，而且这些后续操作与断开前的操作完全没有连续性。

(4)由于暂时缓存在手机内存中的历史数据在手机关机重启后一并消失，因而客户端设备将无法重置成上一次使用时候需要维持的任何状态。

发明内容

鉴于上述缺陷，本申请的一个目的是提供一种更加安全、高效的手机与服务器之间的通讯方法及***，其特别适用于电信计费领域中的音乐客户端软件，可以杜绝这个领域中产生的非法请求而导致错误计费的现象。

本申请的另一个目的是提供一种可以减少对手机硬件(成本)中存储器件的依赖以使其涉及的手机覆盖面更广的手机与服务器之间的通讯方法及***。

本申请的又一个目的是提供一种充分发挥服务端设备运算能力更强大的优势的手机与服务器之间的通讯方法及***，其能更好地利用移动网络中的带宽，更快速地完成指令数据的推送。

本申请的再一个目的是提供一种在时间上无限地延续通讯命令的持续性操作的手机与服务器之间的通讯方法及***。

为了实现上述目的，本申请提出一种手机与服务器之间的通讯方法，包括如下步骤：(1)服务器接收手机发送的请求一文件的数据请求；(2)根据该数据请求，服务器以文件块的形式向手机发送所请求的文件，并将发送的文件块的位置实时记录在缓存设备中；以及(3)当手机与服务器的连接断开后，服务器在接收到手机重发的数据请求时，根据该缓存设备中记录的文件块的位置进行后续文件块的传送。

本申请还提出一种与手机进行通讯的***，包括：服务器，用于与手机进行通讯；和缓存设备，设置于服务器内或者独立于服务器设置；其中，服务器在接收到手机发送的请求一文件的数据请求时，以文件块的形式向手机发送所请求的文件，并且将发送的文件块的位置实时记录在缓存设备中；以及其中，服务器在与手机的连接断开后，接收到手机重发的数据请求时，根据该缓存设备中记录的文件块的位置进行后续文件块的传送。

利用本申请，可以更加安全、高效地进行计费。

利用本申请，可以减少对手机硬件(成本)中存储器件的依赖，使其涉及的手机覆盖面更广。

利用本申请，可以充分发挥服务端设备运算能力更强大的优势，服务端设备的多线程机制可让客户端设备和服务端设备同时建立起多个并发通信通道，进而更好地利用了移动网络中的带宽，更快速地完成指令数据的推送。

利用本申请，由于服务端设备增加了缓存设备，客户端设备请求所产生的任何数据均可完整保留，可在时间上无限地延续通讯命令的持续性操作，不会因为手机客户端的断电或关机而影响到下次运行客户端设备软件时历史请求数据的正常恢复，可以在此基础上开发更好的人机交互***，使客户端设备在任何异常情况下都不会白白的浪费通信资源。

利用本申请，通过扩展客户端设备与服务端设备协议的模型，避免了由于设备间数据伪操作带来的安全风险，避免了移动网络资源的浪费，减低了手机硬件的损耗以及成本，增加的history命令字解决了人机交互中客户端设备的异常而容易导致的产生重复而又固定不灵活的指令操作的问题。

本申请包括但不限于如上优点。当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

图1示出了安全登录校验模型的时序图；

图2示出了客户端多线程模型的时序图；

图3示出了客户端缓存模型的流程图；

图4示例性示出了根据本申请实施例的双向动态安全校验模型的时序图的一实例；

图5示例性示出了根据本申请实施例的服务端多线程缓存扩展时序图的一实例；以及

图6示例性示出了根据本申请实施例的history命令字的关键时序图的一实例。

具体实施方式

在本说明书中，除非明确说明，所提及的“客户端设备”为音乐类手机，其能够经由无线网络与服务器通信；所提及的“服务端设备”为为音乐类手机提供音乐下载、播放等服务的服务器。而且，在此示出的实例仅为示例性，并不旨在限制本申请的范围。

本申请对SSM、MTM和CCM三个模型进行了扩展，在服务端设备增加“历史数据留存模型(history restore module for server，HRM)”，并且在服务端设备一侧增加了缓存设备和安全校验设备。

1、双向动态安全校验扩展

根据一个实施例，将双向动态安全校验模型引入手机与服务器之间的通讯中。在该双向动态安全校验模型中，在服务端设备一侧设置一安全校验设备。根据通讯***的具体情况，该安全校验设备可以结合在服务端设备内，也可以独立于服务端设备。这种模型可以使通讯更加安全，且尤其适用于带有电信计费机制的音乐类手机。

下面将对本实施例的双向动态安全校验模型进行详细描述。

首先，由客户端设备发送密码校验命令pass，服务端设备对从客户端设备发送来的密码校验命令pass进行安全校验，以判断客户端的请求是否属于合法的请求。若密码校验通过，则从服务端设备发送响应字(确认字符串)ok给客户端，这一验证步骤与背景技术部分描述的验证步骤相同。然后，客户端设备向服务端设备发送携带设备唯一标识MDN(mobile directorynumber)的初始化指令init，之后根据客户端设备的每次请求，由服务端设备一侧设置的安全校验设备随机生成并传递给客户端设备一个随机数m和加密串c，而在下一次的请求中客户端设备需要将此随机数m和加密串c以及设备唯一标识MDN传输给服务端设备，服务端设备一侧的安全校验设备在校验了此次请求的合法性后随机又生成一次随机数m和加密串c，并且用新生成的随机数m和加密串c替换掉安全校验设备的内存中原来的随机数m和加密串c。

现参考图4，以命令字init、list和items的操作举例，描述根据本申请实施例的双向动态安全校验模型的时序的一实例。首先，客户端设备发送密码校验命令pass给服务端设备，若验证通过，则服务端设备发送响应字ok给客户端设备。然后，客户端设备发送初始化指令init给服务端设备，该初始化指令携带有MDN，其中“携带”是指该指令init后的数据段携带有MDN或者利用单独的通信信道携带MDN。服务端设备根据该指令init对数据进行初始化，并将客户端设备的请求发送给安全校验设备。该安全校验设备根据客户端设备的请求随机生成随机数m1和加密串c1，并将生成的随机数m1和加密串c1存储在其内存中。若初始化成功，则将携带生成的随机数m1和加密串c1的响应字welcome发送给客户端设备。之后，客户端设备向服务端设备发送携带MDN以及在上一步骤中从服务端设备接收来的随机数m1和加密串c1的指令list。服务端设备一侧的安全校验设备将此次从客户端设备发送来的随机数和加密串与其内存中已存储的随机数和加密串进行比较。如果二者相同，则校验通过，服务端设备执行指令list进行列表，且安全校验设备再次随机生成新的随机数m2和密码串c2，并将新生成的随机数m2和密码串c2存储在其内存中。将新生成的随机数m2和密码串c2携带在响应字list song data中发送给客户端设备。之后，根据从客户端设备发送来的包含MDN以及随机数m2和加密串c2的指令items，服务端设备对随机数m2和加密串c2进行校验，并在校验通过的情况下，执行指令items，并再次生成新的随机数m3和加密串c3，将新生成的随机数m3和加密串c3携带在响应字song items data中发送给客户端设备。在上述步骤中，若从客户端设备发送来的随机数和加密串与安全校验设备的内存中存储的随机数和加密串不匹配，则校验失败，拒绝客户端设备接入服务端设备。

该模型可以很好地杜绝常见的一种客户端命令伪操作行为：如某客户端设备A为安装了正常合法的客户端软件的终端，客户端设备B安装了非法的盗取了客户端设备A所分配的用户名和密码的客户端软件，于是在利用命令user和pass进行验证均通过的情况下，客户端设备B在发送指令init给服务端设备的时候，由于传递的终端唯一标识MDN信息与服务端的不匹配，进而无法生成正确的m和c传递给客户端，于是服务端设备和客户端设备A均可以正确地判定该客户端设备B是安装了非法客户端软件的客户端设备，从而拒绝提供服务。这样可以更好地拒绝任何非法的客户端请求，从而可以确保最大限度的安全性。

而且，该模型还可以提供如下作用：当客户端设备A被木马病毒感染时，由于每次通信校验密码是动态的，木马无法轻易截取到校验规则，增大了木马破解的技术难度，由于密码生成点的随机性、结对性和数据的加密性，绕过这个密码m和c过程的破解方法显而易见是无法被服务端通过的，即使采取唯一的暴力方法破解掉，但客户端设备A可能已经由于资源耗尽而不能使用或者也只能在客户端设备A上进行远程模拟伪操作，而由于如前所述的伪操作的不可行性，并不能转移到客户端设备B上，则这种破解又失去了任何意义。因而，该模型可以使得通讯更为安全可靠。

2、服务端多线程缓存扩展

根据一个实施例，对服务端设备进行多线程缓存扩展以形成服务端多线程缓存模型。该模型主要针对于客户端设备同时发起2个以上素材资源请求的情况。当客户端设备仅发送1个素材资源请求时，服务端设备可以采用单线程模式。在服务端多线程缓存模型中，在服务端设备一侧设置一缓存设备，根据通讯***的具体情况，该缓存设备可以结合在服务端设备内，也可以独立于服务端设备。在下面的说明中，将以缓存设备与服务端设备彼此独立的情况为例进行描述。

下面将对根据本实施例的服务端多线程缓存模型进行详细描述。

在客户端设备请求同时下载多个文件时，客户端设备和服务端设备均采用多线程模式，从而可以将在客户端设备同时下载多个文件时本来由客户端设备完成的任务转移到服务端设备进行；并且由于在服务端设备增加了缓存设备，因而得到的资源信息可以被缓存处理，这样不仅能够减少客户端设备的硬件损耗、最大限度地利用移动网络带宽，还可让客户端设备在重复下载或重复批量播放歌曲的时候根据定义好的标识直接从缓存设备中取出相应数据，减少在查找资源数据时由服务端设备磁盘I/O的低效率运作而导致的时间延迟。

现参照图5，详细描述根据本申请实施例的服务端多线程缓存的过程。首先，客户端设备向服务端设备发送指令items请求获得音乐信息，服务端设备根据此请求向客户端设备发送响应字song items info。之后，客户端设备以多线程模式向服务端设备发送下载指令download请求下载N个对象(iteml，item 2，...item N)，服务端设备首先在缓存设备中寻找所请求下载的对象，若有，则直接将缓存设备中的相应文件(file1，file 2，...file N)以多线程模式发送给客户端设备；若无，则继续在磁盘存储设备中寻找，然后将相应文件(file1，file 2，...file N)以多线程模式发送给客户端设备。

在这种扩展下，不仅通过使用缓存设备来加速请求响应的效率，而且在客户端设备同时发起N(N＞＝2)个素材资源请求的时候，服务端设备也会同时启动N个线程进行处理，服务端设备采用这种多线程模式将会充分地利用服务端设备高性能处理器的优势，即使对于缓存设备中不存在的数据，也能高效地从磁盘上读取到相应数据，而这时由于客户端设备与服务端设备通信的进程内双方均采取多线程连接的方式，因而即使客户端设备由于硬件的能力不足而导致“偏向”单个资源的处理，但是总体上看，可以使“偏向”效应降低很多，这是因为服务端设备在客户端设备处理单个资源时将会源源不端地发送其它资源的数据包，客户端设备将不得不腾出时间片来处理这些数据包，而不是像MTM模型中虽然客户端设备发送了多个资源请求，但是服务端设备却只能等待单个文件处理完全完成后才能处理下一个，导致服务器时间资源成本的浪费。

3、断点续传服务端扩展

由于无线网络不稳定因素的存在(如进入信号弱覆盖区域时)，传统的MTM方式很容易在网络异常时丢失有关下载到客户端设备的数据包的情况，而不得不重新发送原始的数据请求，服务端设备则只有从头重新进行数据包的传输，这不光浪费了网络资源，而且还消耗了大量的重复数据包传送的时间。

针对这一情况，根据本申请的一个实施例，对服务端设备进行了断点续传服务的扩展。在这种扩展的断点续传服务中，首先，在服务端设备设定一个经验时间的范围(优选为24小时或48小时)，当在该时间范围内服务端设备接收到因网络暂断等原因使得客户端设备与服务端设备断开连接后从客户端设备重新发送的数据请求后，服务端设备将上次传输中已经记录在服务端设备的缓存设备里的文件块位置等信息及时响应给客户端，由客户端设备识别并向服务端设备提交用于完成后续文件块的接收工作的请求，从而服务设备端可以根据客户端设备的此请求将后续文件块发送给客户端设备。

现将描述在本实施例中如何在数据传输过程中在服务端设备的缓存设备里实时记录文件块位置。首先，在发送初始化指令init的时候，服务端设备根据客户端设备型号的特性推送一个适合于该客户端设备文件***能够识别的最大文件块大小(block size)数据，当请求的资源文件大于这个文件块大小的时候，传输时服务端设备根据这个块大小将一个文件平均分成几份来传输。而在传输时服务端设备将启动一个监控线程(monitor thread)一直不停地去“监视”每一个数据传输线程中每个文件块的传输情况，例如哪个客户端设备请求哪个资源文件，资源文件一共可分为几块，已经传输完成了第几个块，该文件传送线程是否因为网络异常已经退出等信息。从而可以将文件块的位置实时记录在服务端设备的缓存设备中。

其中，监控线程的时间间隔与资源文件的大小有关，例如，可将其定义为如下面的表1所示：

表1

4、服务端历史数据缓存模型(HRM)

如上所述，客户端设备缓存的数据会因电力、故障等原因而丢失，因而根据本申请的一个实施例，通过在服务端设备形成服务端历史数据缓存模型(HRM)，可以避免手机开机后“一切都需要重新来过”的问题。服务端设备的缓存设备将客户端设备最后一次正常登录校验到初始化后一直到网络断开连接前的所请求的所有命令字和请求的数据包全部进行缓存，并且至少保留一设定的经验时间(优选为一个月时间)，待客户端设备恢复正常、重新校验并初始化完成后，客户端设备可以很快地恢复数据到最后一次指令所形成的操作状态中，进而让客户端设备更好地完成人机交互工作。

在此模型中，在协议中增加命令字：history，且服务端设备响应成功的指令为history ok，失败则为none(表示无上次请求的历史数据)。即，客户端设备与服务端设备的通信协议更改为如下模式(“|”表示“或”的关系，back、exit和list含义同背景技术中所提)：

conn-＞user-＞pass-＞init-＞history|-＞list-＞items-＞download或play

|-＞items-＞download或play

|-＞download或play

下面将参考图6描述命令字history的关键时序的一实例。首先，客户端设备通过发送指令user和pass进行安全校验，在校验通过后，客户端设备发送携带MDN的初始化命令init并从服务端设备返回随机数m和密码串c。接着，客户端设备发送携带MDN、随机数m和密码串c的命令字history给服务端设备，若服务端设备存在上次请求的历史数据，则服务端设备将表示成功的响应字History ok发送给客户端设备，从而使客户端设备恢复数据到最后一次指令所形成的操作状态，并执行最后一次指令；若服务端设备没有上次请求的历史数据，则服务端设备将表示失败的响应字none发送给客户端设备，从而进入正常的通讯过程。

本申请技术方案有益效果包括如下几个方面：

1.可以更加安全、高效，特别适用于电信计费领域中的音乐客户端软件，可以杜绝这个领域中产生的非法请求而导致错误计费的现象；

2.可以减少对手机硬件(成本)中存储器件的依赖，使其涉及的手机覆盖面更广；

3.充分发挥服务端设备运算能力更强大的优势，服务端设备的多线程机制可让客户端设备和服务端设备同时建立起多个并发通信通道，进而更好地利用了移动网络中的带宽，更快速地完成指令数据的推送；

4.由于服务端设备增加了缓存设备，客户端设备请求所产生的任何数据均可完整保留，可在时间上无限地延续通讯命令的持续性操作，不会因为手机客户端的断电或关机而影响到下次运行客户端设备软件时历史请求数据的正常恢复，可以在此基础上开发更好的人机交互***，使客户端设备在任何异常情况下都不会白白的浪费通信资源。

通过扩展客户端设备与服务端设备协议的模型，避免了由于设备间数据伪操作带来的安全风险，避免了移动网络资源的浪费，减低了手机硬件的损耗以及成本，增加的history命令字解决了人机交互中客户端设备的异常而容易导致的产生重复而又固定不灵活的指令操作的问题。

本文记载的所有例子和条件性语言均用于教导目的，以帮助读者理解本申请以及发明人对于现有技术改进所贡献的构思，应将其解读为不是对具体记载的例子和条件的限制。尽管已经详细描述了本申请的实施例，但应理解在不偏离本申请的精神和范围下可以进行各种变化、替换和变更。

Claims (16)

1.一种手机与服务器之间的通讯方法，包括如下步骤：

(1)服务器接收手机发送的请求一文件的数据请求；

(2)根据该数据请求，服务器以文件块的形式向手机发送所请求的文件，并将发送的文件块的位置实时记录在缓存设备中；以及

(3)当手机与服务器的连接断开后，服务器在接收到手机重发的数据请求时，根据该缓存设备中记录的文件块的位置进行后续文件块的传送。

2.根据权利要求1所述的通讯方法，还包括如下步骤：将手机与服务器的连接断开前手机最后一次正常登陆所请求的所有命令字和数据包缓存在该缓存设备中；以及当手机与服务器的连接断开后手机重新发出连接请求时，服务器基于该缓存设备中缓存的内容使得手机恢复到连接断开前最后一个命令的操作状态。

3.根据权利要求1所述的通讯方法，其中，在步骤(1)之前还包括双向动态安全校验步骤。

4.根据权利要求3所述的通讯方法，其中，该双向动态安全校验步骤包括：服务器在每次接收到手机的请求时，控制安全校验设备随机生成并在该安全校验设备内存储随机数和加密串，并将生成的随机数和加密串传递给手机，通过将在手机的下一次请求中发送来的随机数和加密串与所述安全校验设备中存储的随机数和加密串进行对比来验证手机的合法性。

5.根据权利要求1所述的通讯方法，还包括：当接收到手机同时下载多个文件的请求时，服务器以多线程方式进行响应。

6.根据权利要求1所述的通讯方法，其中，步骤(2)包括：服务器根据手机的特性向手机推送手机能够识别的最大文件块大小的数据，当请求的文件大于所述最大文件块大小时，服务器根据所述最大文件块大小将请求的文件平均分成多份。

7.根据权利要求1所述的通讯方法，其中，步骤(2)包括：服务器以预定时间间隔监视文件块的传输情况。

8.根据权利要求7所述的通讯方法，其中，所述预定时间间隔根据请求的文件的大小而设定。

9.一种与手机进行通讯的***，包括：

服务器，用于与手机进行通讯；和

缓存设备，设置于服务器内或者独立于服务器设置；

其中，服务器在接收到手机发送的请求一文件的数据请求时，以文件块的形式向手机发送所请求的文件，并且将发送的文件块的位置实时记录在缓存设备中；以及

其中，服务器在与手机的连接断开后，接收到手机重发的数据请求时，根据该缓存设备中记录的文件块的位置进行后续文件块的传送。

10.根据权利要求9所述的***，其中，该缓存设备存储手机与服务器的连接断开前手机最后一次正常登陆所请求的所有命令字和数据包；以及服务器在手机与服务器的连接断开后手机发起连接请求时，基于该缓存设备中缓存的内容使得手机恢复到连接断开前最后一个命令的操作状态。

11.根据权利要求9所述的***，其中，该***还包括安全校验设备，其，设置于服务器内或者独立于服务器设置。

12.根据权利要求11所述的***，其中，该安全校验设备根据手机的每次请求随机生成并在其内存储随机数和加密串，将生成的随机数和加密串传递给手机，以及通过将在手机的下一次请求中发送来的随机数和加密串与所述安全校验设备中存储的随机数和加密串进行对比来验证手机的合法性。

13.根据权利要求9所述的***，其中，服务器在手机同时下载多个文件时以多线程方式进行响应。

14.根据权利要求9所述的***，其中，服务器根据手机的特性向手机推送手机能够识别的最大文件块大小的数据，且当请求的文件大于所述最大文件块大小时，服务器根据所述最大文件块大小将请求的文件平均分成多份。

15.根据权利要求9所述的***，其中，服务器以预定时间间隔监视文件块的传输情况。

16.根据权利要求15所述的***，其中，所述预定时间间隔根据请求的文件的大小而设定。

Images