CN1859124A - 一种利用无线乡村协议进行数据传输的方法和系统 - Google Patents
一种利用无线乡村协议进行数据传输的方法和系统 Download PDFInfo
- Publication number
- CN1859124A CN1859124A CN 200610065927 CN200610065927A CN1859124A CN 1859124 A CN1859124 A CN 1859124A CN 200610065927 CN200610065927 CN 200610065927 CN 200610065927 A CN200610065927 A CN 200610065927A CN 1859124 A CN1859124 A CN 1859124A
- Authority
- CN
- China
- Prior art keywords
- data
- client
- server
- capacity
- request information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
Abstract
本发明公开了一种利用WV协议进行数据传输的方法,包括:客户端根据客户端数据传输能力容量和待上传的数据容量确定数据传输方式,客户端与服务器根据数据传输方式进行数据传输,即客户端向服务器上传数据,或者客户端从服务器上下载数据。本发明还公开了一种利用WV协议进行数据传输的系统,包括客户端和服务器。根据本发明,通过对WV协议的扩展,可以使客户端的记录上传到服务器,或从服务器上将上传的记录下载到客户端,以及将记录从服务器上删除。从而为WV协议提供了更强的业务能力,满足当前移动终端以及Internet接入方式下客户端记录上传下载的需求。
Description
技术领域
本发明涉及一种通信技术,尤其涉及一种利用WV(无线乡村)协议进行数据传输的方法和系统。
背景技术
随着通讯技术的发展,WV协议作为一种国际标准的即时通讯协议,能够允许不同厂商间的设备进行交互,其应用场景也越来越广泛。WV协议最典型的应用是其可提供IMPS(即时消息和呈现信息)业务,所述的IMPS业务在无线网络中为用户提供即时通讯服务。当前正式批准发布的IMPS业务版本有IMPSV1.1和IMPSV1.2、IMPSV1.3,它们都是基于WV协议的。
IM(即时消息)是个人对个人或个人对群组的即时消息。呈现信息是动态变化的、能被他人获知的用户的状态和属性,可以用来表现自我、共享信息和服务控制。IMPS业务可以通过文本(如聊天记录)、多媒体信息(如语音、图片)等多种类型的信息来传送IM和呈现信息。目前,IMPS业务应用非常广泛,而且用户经常希望将即时通信的记录保存起来,以便下次继续进行与上次即时通信有关的通信,或将通信记录留作记念。
然而,由于WV协议在制定之初的主要目的是为了满足移动终端之间的即时通讯需求,所以在协议中并没有涉及到即时通信记录上传到服务器或从服务器上下载到客户端技术方案。
发明内容
本发明的目的是提供一种利用WV协议进行传输数据的方法和系统,能够方便地将客户端的即时通信记录上传到服务器,以及将服务器上的即时通信记录下载到客户端。
本发明公开了一种上传数据的方法,应用于无线乡村协议中,包括:
A、客户端根据客户端数据传输能力容量和待上传的数据容量向服务发送待上传的数据;
B、服务器将客户端发送的数据保存起来。
所述的步骤A具体包括:
A1、当客户端数据传输能力容量大于或等于待上传的数据容量时,采取单条上传方式向服务器上传数据;
A2、当客户端数据传输能力容量小于待上传的数据容量时,采取分批上传方式向服务器上传数据。
所述的步骤A1具体包括:
A11、客户端向服务发送保存数据请求消息,所述保存数据请求消息包括待上传的数据内容和数据类型;
A12、服务器向客户端返回保存数据响应消息。
所述的步骤A2具体包括:
A21、客户端根据客户端数据传输能力容量分割待上传的数据;
A22、客户端向服务器发送保存数据请求消息,所述保存数据请求消息包括待上传的数据内容和数据类型;
A23、服务器向客户端返回保存数据响应消息;
A24、返回步骤A22,直到最后一批待上传数据传输完毕。
本发明还公开了一种下载数据的方法,应用于无线乡村协议中,包括:
C、客户端获得待下载的数据列表;
D、客户端根据待下载的数据列表确定下载数据标识;
E、客户端根据客户端数据传输能力容量从服务器上下载与下载数据标识相对应的数据。
所述的步骤E具体包括:
E1、当客户端数据传输能力容量大于或等于待下载的数据容量时,采取单条下载方式从服务器下载数据;
E2、当客户端数据传输能力容量小于待下载的数据容量时,采取分批下载方式从服务器下载数据。
所述的步骤E1具体包括:
E11、客户端向服务发送获取数据请求消息,所述的获取数据请求消息包括数据类型;
E12、服务器向客户端返回获取数据响应消息,所述的获取数据响应消息包括待下载的数据。
所述的步骤E2具体包括:
E21、服务器根据客户端数据传输能力容量分割待下载的数据;
E22、客户端向服务器发送获取数据请求消息;
E23、服务器向客户端返回获取数据响应消息;
E24、返回步骤E22,直到最后一批待下载数据传输完毕。
所述的方法还包括步骤:
客户端获得待删除的数据列表;
客户端在待删除的数据列表中确定删除数据标识;
客户端向服务器发送删除数据请求消息,所述的删除数据请求消息包括删除数据标识;
服务器删除与删除数据标识相应的数据。
本发明还公开了一种利用无线乡村协议进行数据传输的系统,包括:
客户端,用于根据客户端的数据传输能力确定上传数据方式,并根据上传数据方式向服务器发送保存数据请求消息和根据下载数据方式向服务器发送获取数据请求消息,接收服务器的保存数据响应消息和获取数据响应消息;
服务器,用于根据客户端的数据传输能力确定下载数据方式,并根据上传数据方式向客户端发送保存数据响应消息和根据下载数据方式向客户端发送获取数据响应消息,接收保存数据请求消息和获取数据请求消息。
根据本发明,通过对WV协议的扩展,可以使客户端的数据上传到服务器,或从服务器上将上传的数据下载到客户端,以及将上传的数据从服务器上删除。从而为WV协议提供了更强的业务能力,满足当前移动终端以及Internet接入方式下客户端数据上传下载的需求。
附图说明
图1示出了本发明实施例的聊天记录的单条上传过程;
图2示出了本发明实施例的聊天记录的分批上传过程;
图3示出了本发明实施例的聊天记录的单条下载过程;
图4示出了本发明实施例的聊天记录的分批下载过程;
图5示出了本发明实施例的聊天记录的删除过程;
图6示出了本发明的数据传输的系统。
具体实施方式
为了便于本领域一般技术人员理解和实现本发明,现结合附图描绘本发明的实施例。
在WV协议中,客户端可以接收和发送各种类型的即时通信记录数据,例如,聊天记录、短消息收发的历史记录、MMS(多媒体消息业)收发的历史记录等等。在即时通信中,由于绝大多数客户端都可以接收和发送聊天记录,为了描述方便,本发明以聊天记录为例来描述在WV协议中实现上传下载的过程。其他的即时通信记录(例如短消息收发的历史记录、MMS收发的历史记录等等)的上传下载过程与聊天记录的上传下载过程完全相同,因此本发明不再一一描述。
本发明的基本思想是,当客户端向服务器上传聊天记录时,客户端首先将聊天记录转换成约定格式的记录,然后将约定格式的记录发给服务器,所述的约定格式为客户端与服务器协商好的格式。当客户端从服务器下载聊天记录时,客户端向服务器发送下载数据请求,所述的下载数据请求包括客户端的传输能力容量,然后根据下载数据请求将下载的聊天记录转换为本地记录。
对于较多内容聊天记录的传输,如聊天记录的容量超过客户端传输能力的容量时,客户端需要对聊天记录分批上传或分批下载。
(1)对于上传过程,客户端根据聊天记录的容量和客户端的传输能力容量来传输聊天记录。若聊天记录的容量大于客户端的传输能力容量,则将聊天记录分为若干段分批上传。即需要向服务器发送多条保存数据请求消息,以便将所有的聊天记录上传到服务器。
(2)对于下载过程,客户端向服务器发送下载数据请求,所述的下载数据请求中包括客户端的传输能力容量,服务器接收到客户端的下载数据请求后,根据聊天记录的容量和客户端的传输能力容量来传输聊天记录。若聊天记录的容量大于客户端的传输能力容量,则将聊天记录分为若干段分批下载。即客户端向服务器发送多条获取数据请求消息,服务器接收到获取数据请求消息后,根据接收的下载请求消息将聊天记录发送给客户端。
下面参照附图描述本发明的聊天记录的上传和下载过程。
一、聊天记录的上传
根据聊天记录的容量和客户端的数据传输能力的大小,上传方式可分为单条上传和分批上传。当聊天记录的容量小于或等于客户端的数据传输能力容量时,可采用单条上传方式;当聊天记录的容量大于客户端的数据传输能力容量时,需要采用分批上传方式。下面分别对采用单条上传方式和采用分批上传方式上传数据的流程进行详细描述。
1、聊天记录的单条上传流程
客户端根据自身的数据传输能力判断可以一次上传聊天记录内容时,即,聊天记录内容的容量小于客户端的数据传输能力时,这时触发单条上传流程,如图1所示,下面描述聊天记录的单条上传流程。
步骤11、客户端向服务器发送保存数据请求消息,由于是单条上传流程,可以将保存数据请求消息中TotolCount(上传次数)参数设置为1,或者省略该参数。所述的保存数据请求消息如表1所示,其包括数据类型(DateType)、数据编码(DateEncoding)、数据内容(DateContent)等。
表1
参数 | 类型 | 描述 |
TotalCount(上传次数) | Integer | 指示分批上传的总批次的数量 |
DataType(数据类型) | String | MIME type as defined in[RFC2045]and[RFC2046]. |
DataEncoding(数据编码) | String | |
DataContent(数据内容) | String | |
Memo(注释) | String |
所述的保存数据请求消息的定义(以XML语言为例)如下。
<!ELEMENT PutData-Request((DataID,DataIndex)?,TotalCount?,DataType?,DataEncoding,DataContent,Memo?)>
其中带“?”的参数为可选项。
步骤12、服务器收到客户端的保存数据请求之后,由于保存数据请求消息中TotolCount参数不存在或者TotolCount参数值为1,则判断出本次上传为单次上传,且DataType为“聊天记录”,则把DataContent中内容保存起来,如保存到数据库或者文件中,最后通过保存数据响应消息将操作结果返回给客户端,所述的操作结果包括成功和失败,当操作结果为失败时,客户端需要重新上传该聊天记录;当操作结果为成功时,结束本次上传过程。
所述的保存数据响应消息的定义(以XML语言为例)如下。
<!ELEMENT PutData-Response(Result,DataID?)>
其中带“?”的参数为可选项。
2、聊天记录分批上传流程
客户端根据自身的数据传输能力和聊天记录内容的容量判断需要分批上传聊天记录内容时,即,聊天记录内容的容量大于客户端的数据传输能力时,这时触发分批上传流程。在分批上传前,需要确定上传的次数,具体而言,客户端首先将聊天记录分为多批,并为每一批加上批次。每一批的容量小于或等于客户端的最大数据传输能力容量,例如,可以将客户端的最大传输能力容量确定为单次传输的容量。下面参照图2描述聊天记录的分批上传流程。
步骤21、客户端向服务器发送保存数据请求消息,由于是分批上传,客户端将保存数据请求消息中TotolCount参数设置为该聊天记录的上传次数。所述的保存数据请求消息如表2所示,其包括上传次数(TotalCount)、数据类型(DateType)、数据编码(DateEncoding)、数据内容(DateContent)等。所述的上传次数大于1。
表2
参数 | 类型 | 描述 |
TotalCount(上传次数) | Integer | 指示分批上传的总批次的数量 |
DataType(数据类型) | Integer | 指示数据类型是“聊天记录” |
DataEncoding(数据编码) | String | |
DataContent(数据内容) | String | |
Memo(注释) | String |
所述的保存数据请求消息的定义(以XML语言为例)如下。
<!ELEMENT PutData-Request((DataID,DataIndex)?,TotalCount?,DataType?,DataEncoding,DataContent,Memo?)>
其中带“?”的参数为可选项。
步骤22、服务器收到客户端的保存数据请求之后,由于保存数据请求消息中TotolCount参数的值大于1,则认为是分批上传。再通过DataType判断此次上传的数据类型为“聊天记录”,则把此次收到的DataContent保存起来,并为此批数据分配一个DataID(数据标识),以便等待所有批次记录上传完成后将所有DataID相同的各批记录组装起来形成一个完整记录。接着服务器向客户端发送保存数据响应,所述的保存数据响应消息如表3所示,其包括操作结果和DataID。
表3
参数 | 类型 | 描述 |
Result(结果) | Structure | 指示操作结果 |
DataID(数据标识) | Integer | 服务器为此次分批上传分配的唯一标识DataID |
所述的保存数据响应消息的定义(以XML语言为例)如下。
<!ELEMENT PutData-Response(Result,DataID?)>
其中带“?”的参数为可选项。
步骤23、客户端收到保存数据响应消息后,若操作结果为成功,则通过保存数据请求消息上传下一批记录,所述的保存数据请求消息如表4所示,其包括DateID、记录批次和数据内容,若操作结果失败,重传该批记录。
表4
参数 | 类型 | 描述 |
DataID(数据标识) | Integer | 服务器为此次分批上传分配的唯一标识DataID |
DataIndex(记录批次) | Integer | 用于标识分批上传的批次,从1到TotalCount-1,此处值为1 |
DataEncoding(数据编码) | String | |
DataContent(数据内容) | String |
步骤24、服务器收到保存数据请求消息之后,向客户端发送保存数据响应消息,所述的保存数据响应消息如表5所示,接着服务器判断记录批次是否等于TotolCount-1,如果不等于,则认为还有后续批次,继续等待。
表5
参数 | 类型 | 描述 |
Result(结果) | Structure | 指示操作结果 |
这样,通过交替执行步骤23和步骤24,使得除最后批次的所有批次聊天记录上传到服务器;或操作失败,结束本次上传过程。
步骤25、客户端向服务器发送最后一条保存数据请求消息,由于是最后批次记录的上传,客户端将保存数据请求消息中上传批次设置为TotolCount-1。所述的保存数据请求消息如表6所示,其包括记录批次(DateIndex)、数据类型(DateType)、数据编码(DateEncoding)、数据内容(DateContent)等。
表6
参数 | 类型 | 描述 |
DataID(数据标识) | Integer | 服务器为此次分批上传分配的唯一标识DataID |
DataIndex(记录批次) | Integer | 用于标识分批上传的批次,此处值为TotalCount-1 |
DataEncoding(数据编码) | String | |
DataContent(数据内容) | String |
步骤26、服务器收到保存数据请求消息之后,由于DataIndex等于TotolCount-1,则表明该批记录是最后一批。接着服务器根据DataIndex查看所有批次是否收全,如果已经收全,则将所有的批次中的内容整合成一个完整的聊天记录。然后将相应的信息保存起来,如保存到数据库或者文件中。接着向客户端发送保存数据响应消息,所述的保存数据响应消息如表7所示,其包括操作结果。
表7
参数 | 类型 | 描述 |
Result(结果) | Structure | 指示操作结果 |
二、聊天记录的下载
同样,根据聊天记录的容量和客户端的数据传输能力容量的大小,下载方式也可分为单条下载和分批下载。当聊天记录的容量小于或等于客户端的数据传输能力容量时,可采用单条下载方式;当聊天记录的容量大于客户端的数据传输能力容量时,需要采用分批下载方式。下面分别描述采用单条下载方式和分批下载方式下载数据的方法。
1、聊天记录单条下载流程
当聊天记录内容的容量小于客户端的数据传输能力时,这时触发单条下载流程,如图3所示,下面描述聊天记录的单条下载流程。
步骤31、客户端向服务器发送获取数据列表请求消息,所述的获取数据列表请求消息包括数据类型,在本实施例中,数据类型为聊天记录,以便获得服务器上保存的该数据类型的记录。所述的获取数据列表请求消息如表8所示。
表8
参数 | 类型 | 描述 |
DataType(数据类型) | String |
所述的获取数据列表请求消息的定义(以XML语言为例)如下。
<!ELEMENT GetDataList-Request(DataType)>
步骤32、服务器收到获取数据列表请求消息之后,首先从获取数据列表请求消息中获得数据类型,服务器查询数据类型为“聊天记录”所有记录,然后将该用户所有聊天记录通过获取数据列表响应消息返回给客户端。所述的获取数据列表响应消息如表9所示。
表9
参数 | 类型 | 描述 |
DataID(数据标识) | Integer | 服务器为此聊天记录分配的唯一标识DataID |
DateTime(数据上传时间) | 聊天记录上传的时间 | |
DataEncoding(数据编码) | ||
DataSize(数据容量) | Integer | 聊天记录的大小(Byte) |
Memo(注释) | String | 聊天记录的说明 |
所述的获取数据列表响应消息的定义(以XML语言为例)如下。
<!ELEMENT GetDataList-Response(DataInfo*)>
<!ELEMENT DataInfo(DataID,DataType?,DateTime,DataEncoding,DataSize,Memo?)>
其中带“?”的参数为可选项。
步骤33、客户端收到获取数据列表响应消息后,从列表中选择待下载的聊天记录的数据标识(DateID),然后向服务器发送获取数据请求消息,所述的获取数据请求消息包括选择的数据标识,以便获得服务器上保存的聊天记录。所述的获取数据请求消息如表10所示。
表10
参数 | 类型 | 描述 |
DataID(数据标识) | String | 服务器为此数据分配的唯一标识DataID注:由于没有携带GetLimit参数,则表示一次下载全部数据 |
所述的获取数据请求消息的定义(以XML语言为例)如下。
<!ELEMENT GetData-Request(DataID,DataIndex?,GetLimit?)>
其中带“?”的参数为可选项。
步骤34、服务器收到下载请求消息之后,根据下载请求消息中的数据标识(DataID),从数据库或者文件查找出相应的记录,然后将该聊天记录通过获取数据响应消息返回给客户端。所述的获取数据响应消息如表11所示。
表11
参数 | 类型 | 描述 |
DataEncoding(数据编码) | String | |
DataContent(数据内容) | String |
Completion-Flag(结束标志) | Boolean | 指示数据是否已经结束,此处为True |
所述的获取数据响应消息的定义(以XML语言为例)如下。
<!ELEMENT GetData-Response(DataEncoding,DataContent,SubsectionCount?,Completion-Flag)>
其中带“?”的参数为可选项。
2、聊天记录分批下载流程
服务器根据客户端的数据传输能力和聊天记录内容的容量判断需要分批下载聊天记录内容时,即,聊天记录内容的容量大于客户端的数据传输能力时,这时触发分批下载流程。在分批下载前,需要确定下载的次数,具体而言,服务器首先将聊天记录分为多批,并为每一批加上批次。每一批的容量小于或等于客户端的最大数据传输能力容量,例如,可以将客户端的最大传输能力容量确定为单次传输的容量。下面参照图4描述聊天记录的分批上传流程。
步骤41、客户端向服务器发送获取数据列表请求消息,所述的获取数据列表请求消息包括数据类型,在本实施例中,数据类型为聊天记录,以便获得服务器上保存的该数据类型的记录。所述的获取数据列表请求消息如下表所示。
表12
参数 | 类型 | 描述 |
DataType(数据类型) | String |
步骤42、服务器收到获取数据列表请求消息之后,首先从获取数据列表请求消息中获得数据类型,服务器查询数据类型为“聊天记录”所有记录,然后将该用户所有聊天记录通过获取数据列表响应消息返回给客户端。所述的获取数据列表响应消息如表13所示。
表13
参数 | 类型 | 描述 |
DataID(数据标识) | Integer | 服务器为此聊天记录分配的唯一标识DataID |
DateTime(数据上传时间) | 聊天记录上传的时间 | |
DataEncoding(数据编码) | ||
DataSize(数据容量) | Integer | 聊天记录的大小(Byte) |
Memo(注释) | String | 聊天记录的说明 |
步骤43、客户端收到获取数据列表响应消息后,从列表中选择待下载的聊天记录的数据标识(DateID),然后向服务器发送获取数据请求消息,所述的获取数据请求消息包括选择的数据标识、记录批次和下载容量,以便获得服务器上保存的聊天记录。所述的获取数据请求消息如表14所示。
表14
参数 | 类型 | 描述 |
DataID(数据标识) | String | 服务器为此数据分配的唯一标识DataID |
DataIndex(记录批次) | Integer | 分批下载的批号,此处为0 |
GetLimit(下载最大容量) | Integer | 每次下载的数据的最大大小(单位:byte) |
步骤44、服务器收到获取数据请求消息之后,根据获取数据请求消息中的DataID从数据库或者文件中找到对应的记录,然后根据下载容量将数据分割成n份。并将第1份通过获取数据响应消息返回给客户端。所述的获取数据响应消息如表15所示,其包括数据编码、数据内容、总批数和结束标志(Completion-Flag)。若不是最后一批数据,将结果标志设置为False,否则将结果标志设置为True。
表15
参数 | 类型 | 描述 |
DataEncoding(数据编码) | String | |
DataContent(数据内容) | String | |
SubsectionCount(总批数) | Integer | 此次分批下载的分批个数 |
Completion-Flag(结束标志) | Boolean | 指示数据还没有结束,还有后续数据,此处为False |
步骤45-46、客户端依次向服务器发送获取数据请求消息,客户端收到获取数据响应消息后,接着根据获取数据响应消息中的结束标志确定是否向服务器发送获取数据请求消息,即,若结束标志为False,向服务器发送获取数据请求消息,直至收到的获取数据请求消息中的结束标志为True,客户端将所收到的所有批次聊天记录整合成一个完整的聊天记录。所述的获取数据请求消息如表16所示。
表16
参数 | 类型 | 描述 |
DataID(数据标识) | Integer | 服务器为此数据分配的唯一标识DataID |
DataIndex(记录批次) | Integer | 用于标识分批下载的批次,从2到n-2 |
三、删除聊天记录流程
当用户不需要聊天记录时,可以将聊天记录删除。下面结合图5详细描述删除聊天记录的流程。
步骤51、客户端向服务器发送获取数据列表请求消息,所述的获取数据列表请求消息包括数据类型,在本实施例中,数据类型为聊天记录,以便获得服务器上保存的该数据类型的记录。所述的获取数据列表请求消息如表17所示。
表17
参数 | 类型 | 描述 |
DataType(数据类型) | String |
步骤52、服务器收到获取数据列表请求消息之后,首先从获取数据列表请求消息中获得数据类型,服务器查询数据类型为“聊天记录”所有记录,然后将该用户所有聊天记录列表通过获取数据列表响应消息返回给客户端。所述的获取数据列表响应消息如表18所示。
表18
参数 | 类型 | 描述 |
DataID(数据标识) | Integer | 服务器为此聊天记录分配的唯一标识DataID |
DateTime(数据上传时间) | 聊天记录上传的时间 | |
DataEncoding(数据编码) | ||
DataSize(数据容量) | Integer | 聊天记录的大小(Byte) |
Memo(注释) | String | 聊天记录的说明 |
步骤53、客户端收到获取数据列表响应消息后,从列表中选择待删除的聊天记录的数据标识(DateID),然后向服务器发送删除数据请求消息,所述的删除数据请求消息包括选择的数据标识。所述的获取数据请求消息如表19所示。
表19
参数 | 类型 | 描述 |
DataID(数据标识) | String | 用要删除的数据的唯一标识 |
所述的删除数据请求消息的定义(以XML语言为例)如下。
<!ELEMENT DataDelete-Resquest(DataID+)>
其中带“?”的参数为可选项。
步骤54、当服务器收到删除数据请求之后,根据删除数据请求消息中的DataID找到相应的数据,并将其删除,然后向客户端发送删除数据响应消息,所述的删除数据响应消息如表20所示,其包括此次操作结果。
表20
参数 | 类型 | 描述 |
Result(结果) | Structure | 操作结果 |
本发明还公开了一种利用无线乡村协议进行数据传输的系统,如图6所示,所述的系统包括:客户端,用于根据客户端的数据传输能力确定上传数据方式,并根据上传数据方式向服务器发送保存数据请求消息和根据下载数据方式向服务器发送获取数据请求消息,接收服务器的保存数据响应消息和获取数据响应消息;服务器,用于根据客户端的数据传输能力确定下载数据方式,并根据上传数据方式向客户端发送保存数据响应消息和根据下载数据方式向客户端发送获取数据响应消息,接收保存数据请求消息和获取数据请求消息;传输网,用于在客户端和服务器间进行数据传输。所述的客户端可以为移动终端或桌面终端。
根据本发明,通过对WV协议的扩展,可以使客户端的各种记录上传到服务器,或从服务器上将上传的记录下载到客户端,以及将记录从服务器上删除。从而为WV协议提供了更强的业务能力,满足当前移动终端以及Internet接入方式下客户端记录上传下载的需求。
应该注意到,本发明的记录可扩展到一般的数据,即,根据本发明,通过对WV协议的扩展,可以使客户端的数据上传到服务器,或从服务器上将上传的数据下载到客户端,以及将上传的数据从服务器上删除。从而为WV协议提供了更强的业务能力,满足当前移动终端以及Internet接入方式下客户端数据上传下载的需求。
虽然通过实施例描绘了本发明,但本领域普通技术人员知道,在不脱离本发明的精神和实质的情况下,就可使本发明有许多变形和变化,本发明的范围由所附的权利要求来限定。
Claims (10)
1、一种上传数据的方法,应用于无线乡村协议中,其特征在于,包括:
A、客户端根据客户端数据传输能力容量和待上传的数据容量向服务发送待上传的数据;
B、服务器将客户端发送的数据保存起来。
2、根据权利要求1所述的上传数据的方法,其特征在于,所述的步骤A具体包括:
A1、当客户端数据传输能力容量大于或等于待上传的数据容量时,采取单条上传方式向服务器上传数据;
A2、当客户端数据传输能力容量小于待上传的数据容量时,采取分批上传方式向服务器上传数据。
3、根据权利要求2所述的上传数据的方法,其特征在于,所述的步骤A1具体包括:
A11、客户端向服务发送保存数据请求消息,所述保存数据请求消息包括待上传的数据内容和数据类型;
A12、服务器向客户端返回保存数据响应消息。
4、根据权利要求2所述的上传数据的方法,其特征在于,所述的步骤A2具体包括:
A21、客户端根据客户端数据传输能力容量分割待上传的数据;
A22、客户端向服务器发送保存数据请求消息,所述保存数据请求消息包括待上传的数据内容和数据类型;
A23、服务器向客户端返回保存数据响应消息;
A24、返回步骤A22,直到最后一批待上传数据传输完毕。
5、一种下载数据的方法,应用于无线乡村协议中,其特征在于,包括:
C、客户端获得待下载的数据列表;
D、客户端根据待下载的数据列表确定下载数据标识;
E、客户端根据客户端数据传输能力容量从服务器上下载与下载数据标识相对应的数据。
6、根据权利要求5所述的下载数据的方法,其特征在于,所述的步骤E具体包括:
E1、当客户端数据传输能力容量大于或等于待下载的数据容量时,采取单条下载方式从服务器下载数据;
E2、当客户端数据传输能力容量小于待下载的数据容量时,采取分批下载方式从服务器下载数据。
7、根据权利要求6所述的下载数据的方法,其特征在于,所述的步骤E1具体包括:
E11、客户端向服务发送获取数据请求消息,所述的获取数据请求消息包括数据类型;
E12、服务器向客户端返回获取数据响应消息,所述的获取数据响应消息包括待下载的数据。
8、根据权利要求6所述的下载数据的方法,其特征在于,所述的步骤E2具体包括:
E21、服务器根据客户端数据传输能力容量分割待下载的数据;
E22、客户端向服务器发送获取数据请求消息;
E23、服务器向客户端返回获取数据响应消息;
E24、返回步骤E22,直到最后一批待下载数据传输完毕。
9、根据权利要求5至8所述的下载数据的方法,其特征在于,所述的方法还包括步骤:
客户端获得待删除的数据列表;
客户端在待删除的数据列表中确定删除数据标识;
客户端向服务器发送删除数据请求消息,所述的删除数据请求消息包括删除数据标识;
服务器删除与删除数据标识相应的数据。
10、一种利用无线乡村协议进行数据传输的系统,其特征在于,包括:
客户端,用于根据客户端的数据传输能力确定上传数据方式,并根据上传数据方式向服务器发送保存数据请求消息和根据下载数据方式向服务器发送获取数据请求消息,接收服务器的保存数据响应消息和获取数据响应消息;
服务器,用于根据客户端的数据传输能力确定下载数据方式,并根据上传数据方式向客户端发送保存数据响应消息和根据下载数据方式向客户端发送获取数据响应消息,接收保存数据请求消息和获取数据请求消息。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2006100659279A CN100479366C (zh) | 2006-03-27 | 2006-03-27 | 一种利用无线乡村协议进行数据传输的方法和系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2006100659279A CN100479366C (zh) | 2006-03-27 | 2006-03-27 | 一种利用无线乡村协议进行数据传输的方法和系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1859124A true CN1859124A (zh) | 2006-11-08 |
CN100479366C CN100479366C (zh) | 2009-04-15 |
Family
ID=37297991
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNB2006100659279A Expired - Fee Related CN100479366C (zh) | 2006-03-27 | 2006-03-27 | 一种利用无线乡村协议进行数据传输的方法和系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN100479366C (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101257713B (zh) * | 2008-02-02 | 2012-07-04 | 中国联合网络通信集团有限公司 | 移动终端业务使用权限保存及认证方法和系统 |
CN104737580A (zh) * | 2012-09-05 | 2015-06-24 | 瑞典爱立信有限公司 | 用于移动蜂窝网络中受控数据上传的方法和设备 |
-
2006
- 2006-03-27 CN CNB2006100659279A patent/CN100479366C/zh not_active Expired - Fee Related
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101257713B (zh) * | 2008-02-02 | 2012-07-04 | 中国联合网络通信集团有限公司 | 移动终端业务使用权限保存及认证方法和系统 |
CN104737580A (zh) * | 2012-09-05 | 2015-06-24 | 瑞典爱立信有限公司 | 用于移动蜂窝网络中受控数据上传的方法和设备 |
US10028164B2 (en) | 2012-09-05 | 2018-07-17 | Telefonaktiebolaget Lm Ericsson (Publ) | Methods and devices for controlled data upload in mobile cellular networks |
CN104737580B (zh) * | 2012-09-05 | 2019-08-23 | 瑞典爱立信有限公司 | 用于移动蜂窝网络中受控数据上传的方法和设备 |
Also Published As
Publication number | Publication date |
---|---|
CN100479366C (zh) | 2009-04-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN1713177A (zh) | 文件共享系统和客户端装置 | |
CN101035317A (zh) | 一种业务参数配置方法及系统以及业务参数配置单元 | |
CN1913661A (zh) | 消息转换设备与转换方法 | |
CN101075987A (zh) | 一种传送消息的装置和方法 | |
CN1852101A (zh) | 一种并行下载方法和终端 | |
CN1732454A (zh) | 在多个装置上呈现内容的系统和方法 | |
CN101047662A (zh) | 实现单账号多身份即时消息通信和存在业务的方法及系统 | |
CN1694379A (zh) | 移动通信系统和mbms服务相关信息传送方法 | |
CN1723452A (zh) | 传输和下载流数据的方法 | |
CN1960400A (zh) | 通信终端及其接收阻塞方法 | |
CN1522013A (zh) | 用于服务器和客户机间改进的同步的系统和方法 | |
CN1275284A (zh) | 推出型信息传输方法和它的转移设备 | |
CN1794827A (zh) | 一种多媒体广播/组播服务控制信息的接收方法 | |
CN1783133A (zh) | 便携型通信终端设备、分配服务器、内容供应系统和方法 | |
CN1770886A (zh) | 一种蜂窝电话及其传送消息的方法 | |
CN1744606A (zh) | 在终端和服务器之间移动用户个人数据的同步处理方法 | |
CN101068378A (zh) | 实现多媒体消息业务系统容灾的方法、系统及设备 | |
CN1451118A (zh) | 文件传送系统、设备、方法以及存储文件传送程序的计算机可读介质 | |
CN1787665A (zh) | 一种防止移动终端中个人数据丢失的方法及装置 | |
CN101031107A (zh) | 实现短消息广告业务的系统、设备及方法 | |
CN1859270A (zh) | 一种动态内容传送方法与系统 | |
CN1666555A (zh) | 消息发送和接收系统及方法 | |
CN1285229C (zh) | 获取移动用户状态信息的方法、系统及相应用户识别模块 | |
CN1679286A (zh) | 电子邮件传送系统 | |
CN1794721A (zh) | 一种在指定时间下载媒体对象的方法及装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20090415 Termination date: 20150327 |
|
EXPY | Termination of patent right or utility model |