CN102355426B - 实现离线文件传输的方法和系统 - Google Patents
实现离线文件传输的方法和系统 Download PDFInfo
- Publication number
- CN102355426B CN102355426B CN201110183229.XA CN201110183229A CN102355426B CN 102355426 B CN102355426 B CN 102355426B CN 201110183229 A CN201110183229 A CN 201110183229A CN 102355426 B CN102355426 B CN 102355426B
- Authority
- CN
- China
- Prior art keywords
- server
- line files
- instant communication
- file
- files
- 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.)
- Active
Links
Landscapes
- Information Transfer Between Computers (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种实现离线文件传输的方法和系统,丰富了即时通信系统的功能,能够快速实现离线文件的上传和下载,提高了用户体验。本发明实施例提供的方法包括:当作为接收方的第二即时通信客户端处于离线状态时,作为发送方的第一即时通信客户端与离线文件服务器建立HTTP连接,并通过所述HTTP连接将离线文件上传至离线文件服务器;离线文件服务器将接收到的离线文件传输至高效分布式文件系统FastDFS存储器并保存;第二即时通信客户端上线后,根据接收到的离线文件接收通知,与离线文件服务器建立HTTP连接;第二即时通信客户端通过离线文件服务器从FastDFS存储器下载得到相应的离线文件。
Description
技术领域
本发明涉及通信技术领域,尤其是涉及一种实现离线文件传输的方法和系统。
背景技术
即时通信(Instant Messaging,IM)技术能够提供即时发送和接收互联网消息等业务。随着通信技术的发展,即时通信的功能也日益丰富,即时通信系统不再是一个单纯的聊天工具,而逐渐发展为集成电子邮件、博客、音乐、电视、游戏和搜索等多种功能为一体的综合化信息平台。
然而,在现有的即时通信功能也存在一些缺点,例如,在目前的即时通信功能中,只有当两个即时通信客户端同时处于在线状态时,才能在双方之间进行文件的传输,如果文件的接收方不在线,那么文件的发送方便无法成功将文件发送给接收方,从而给使用者带来了不便,降低了用户体验。
发明内容
本发明实施例提供了一种实现离线文件传输的方法和系统,能够丰富即时通信系统的功能,快速实现离线文件的上传和下载,提高了用户体验。
为达到上述目的,本发明实施例的技术方案是这样实现的:
本发明实施例提供了一种实现离线文件传输的方法,该方法包括:
当作为接收方的第二即时通信客户端处于离线状态时,作为发送方的第一即时通信客户端与离线文件服务器建立超文本传输协议HTTP连接,并通过所述HTTP连接将离线文件上传至离线文件服务器;
离线文件服务器将接收到的离线文件传输至高效分布式文件系统FastDFS存储器并保存;
第二即时通信客户端上线后,根据接收到的离线文件接收通知,与离线文件服务器建立HTTP连接;
第二即时通信客户端通过离线文件服务器从FastDFS存储器下载得到相应的离线文件。
本发明实施例还提供了一种实现离线文件传输的系统,所述系统包括至少两个即时通信客户端、至少一个离线文件服务器和FastDFS存储器,所述即时通信客户端包括作为发送方的第一即时通信客户端和作为接收方的第二即时通信客户端,
所述第一即时通信客户端,用于当第二即时通信客户端处于离线状态时,与离线文件服务器建立HTTP连接,并通过所述HTTP连接将离线文件上传至离线文件服务器;
所述离线文件服务器,用于将接收到的离线文件传输至FastDFS存储器并保存;
所述第二即时通信客户端,用于在上线后,根据接收到的离线文件接收通知,与离线文件服务器建立HTTP连接,并通过离线文件服务器从FastDFS存储器下载得到相应的离线文件;
其中,所述离线文件服务器,还用于通过查询缓存中所保存的文件数据判断当前离线文件是否属于断点续传,若是,将断点位置通知第一即时通信客户端,第一即时通信客户端从断点位置起上传当前离线文件的相应内容;若否,第一即时通信客户端上传当前离线文件的全部内容;以及,
所述第二即时通信客户端,还用于以文件块为单位通过离线文件服务器下载相应的离线文件,在每一个文件块的下载过程中,离线文件服务器先将整个文件块从FastDFS存储器读取出来,然后按照预定容量的字节流将文件块传输至第二即时通信客户端。
由上述可见,本发明实施例提供了一种新型的向离线状态的即时通信客户端传输文件的解决方案,弥补了现有即时通信技术中只能在通信双方同时在线时进行文件传输的缺陷,丰富了即时通信系统的功能,便利了用户的使用,提高了用户体验。
并且,本技术方案通过整体架构和传输流程的设置,能够快速实现离线文件的上传和下载。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本发明实施例一提供的一种实现离线文件传输的方法流程示意图;
图2为本技术方案的一个应用场景的系统结构示意图;
图3为本发明实施例二提供的离线文件上传操作流程示意图;
图4为本发明实施例二提供的离线文件下载操作流程示意图。
具体实施方式
下面将结合本发明的附图,对本发明的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动的前提下所获得的所有其他实施例,都属于本发明保护的范围。
本发明实施例一提供了一种实现离线文件传输的方法,参见图1,所述方法包括:
11:当作为接收方的第二即时通信客户端处于离线状态时,作为发送方的第一即时通信客户端与离线文件服务器建立超文本传输协议HTTP连接,并通过所述HTTP连接将离线文件上传至离线文件服务器;
12:离线文件服务器将接收到的离线文件传输至高效分布式文件系统FastDFS存储器并保存;
13:第二即时通信客户端上线后,根据接收到的离线文件接收通知,与离线文件服务器建立HTTP连接;
14:第二即时通信客户端通过离线文件服务器从FastDFS存储器下载得到相应的离线文件。
由上述可见,本发明实施例提供了一种新型的向离线状态的即时通信客户端传输文件的解决方案,弥补了现有即时通信技术中只能在通信双方同时在线时进行文件传输的缺陷,丰富了即时通信系统的功能,便利了用户的使用,提高了用户体验。
并且,本技术方案通过整体架构和传输流程的设置,能够快速实现离线文件的上传和下载。
为了便于清楚描述本发明实施例的技术方案,在发明的实施例中,采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分,本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定。
为便于清楚说明本技术方案,首先对本技术方案的一个应用场景进行描述,参见图2,在该场景中终端侧包含第一即时通信客户端和第二即时通信客户端,服务器侧包含离线文件服务器(CloudFile Portal Service,CFPS),离线文件业务服务(Cloud File BusinessService),高效分布式文件系统(FastDFS)存储器和CFBS所相应的数据库,即CFBS所能够调用的数据库,在此不对本发明实施例中各设备或单元的具体名称进行限定,例如CFPS也可以称之为离线文件门户服务或CFP服务器,FastDFS存储器也可以缩写为FDFS存储器。在本方案的系统中采用分布式结构的CFP服务器,即通常系统中存在多个CFP服务器,图2中仅简单地示出了存在一个CFP服务器的情况。
本方案的信令调用机制中,发送方和接收方与CFPS建立时采用超文本传输协议(HyperText Transfer Protocol,HTTP)连接。Http是一种建立在TCP协议之上的轻量级协议,同TCP协议相比,更容易穿越企业层层设置的防火墙,而且在使用.NET技术开发的情况下,可以使用互联网信息服务(Internet Information Services,IIS)来方便地解析出包含在HTTP信令中的参数字段。
本方案使用一系列信令步骤来完成上传/下载离线文件的流程。对于上传流程来说,采用了查询-配置-上传会话初始化-数据上传-上传会话结束(Query-Allocate-InitializeSession-PostData-FinishSession)等信令;
对于下载流程来说,采用了配置-下载会话初始化-数据下载-下载会话结束(Allocate-InitializeSession-GetData-FinishSession)等信令。其中,Query信令负责查询当前剩余空间,Allocate分配CFP服务器,InitializeSession开始会话,直到FinishSession的时候结束会话上传/下载过程,离线文件传输结束,这几个信令与业务逻辑紧密结合而又相互独立,组成了即时通信离线文件传输机制的独特的逻辑架构。
本发明的技术构思主要在于通过即时通信客户端建立HTTP连接,在通过服务器侧的身份验证后,查询发送方的当前剩余空间,给将要发送的离线文件分配文件服务器资源,初始化一个离线文件上传会话(Session),发送方以每次8K的大小发送文件字节流(ByteStream)发送给服务器,在整个文件传输完成之前,服务器端都将发送过来的字节流保存在缓存(Buffer)中,文件传输完成后写入FDFS存储器;整个文件如果超过2M,将其分解成以2M为基本单位的文件块,进行分块存储和传输;在整个文件(或文件块)传输完毕之后,会通过校验文件(或文件块)的MD5值来确认文件传输是否完成。
接收方登录后,服务器侧当即推送一个离线文件接收通知,接收方在通过服务器端的身份验证之后,服务器侧初始化一个离线文件下载的会话,多存在多个文件块时,服务器侧从FDFS存储器获取文件块,以每次8K大小的字节流(Byte Stream)发送给接收方。
服务器端和FDFS存储器将维护所保存的离线文件及相关信息,接收方如果在一定时间内没有成功下载到离线文件,服务器端将自动将离线文件清除。
下面对本发明实施例二提供了一种实现离线文件传输的方法进行说明。分别从离线文件的发送方(第一即时通信客户端)的离线文件上传操作和离线文件的接收方(第二即时通信客户端)的离线文件下载操作的信令交互来说明本方案。其中,当第一即时通信客户端上传离线文件时,第二即时通信客户端处于离线状态。
离线文件上传
参见图3,具体包括如下处理:
1:第一即时通信客户端(或表示为Client A)与CFP服务器,建立HTTP连接,发送查询(Query)信令,查询第一即时通信客户端的当前剩余空间,该查询信令还可以查询第一即时通信客户端的在系统的最大文件上传空间。
上述最大文件上传空间指示一定时间(如一天)内允许Client A上传的文件容量最大值,上述当前剩余空间指示Client A当前还能够上传的文件容量的数值。
2:CFP服务器向CFBS发送获取剩余空间请求(GetCommittedSize)。
3:CFBS向CFP服务器返回剩余空间容量。
CFBS通过查询相应的数据库得到当前剩余空间容量。
4:CFP服务器向Client A返回查询响应。
由上述步骤1至4,CFP服务器根据所述查询指令,从离线文件业务服务获取第一即时通信客户端的当前剩余空间容量。可选的,CFP服务器还可以从离线文件业务服务获取Client A的最大文件上传空间。CFP服务器通过查询响应将当前剩余空间容量发送至Client A。该查询响应也可以携带Client A的最大文件上传空间
进一步的,在上述查询指令中,还可以携带Client A的身份信息,CFP服务器还可以对Client A的身份进行认证,当认证通过后,执行后续流程,否则,结束当前流程。
对于大容量文件的传输,本方案采用划分为多个文件块,以文件块为单位传输的方式,这时,查询响应中还可以携带块文件容量配置,在此,块文件容量配置取2M。
Client A收到当前剩余空间容量后,将当前剩余空间与当前离线文件进行比较,若当前剩余空间的容量大于当前离线文件的容量,表明允许文件上传,启动当前离线文件的上传。
5:第一即时通信客户端向离线文件服务器发送配置(Allocate)请求信令,请求服务器侧分配文件服务器资源。
6:离线文件服务器发送信令,向离线文件业务服务获取服务器资源(GetFileServer),即获取上传文件服务器的资源。
7:离线文件业务服务返回上传文件服务器的地址信息(ReturnServer[IP:Port])。
上传文件服务器为从多个CFP服务器中选取的一个服务器。上传文件服务器可以为步骤1中与Client A建立HTTP连接的CFP服务器,也可以为本系统中不同于步骤1中CFP服务器的另一个CFP服务器,在图3中以上传文件服务器为步骤1中CFP服务器为例进行了说明。可以理解,对上传文件服务器与步骤1中CFP服务器不相同的场景,其流程与图3中的流程相似。
通过离线文件业务服务在相应数据库中查询得到为第一即时通信客户端所分配的上传文件服务器的地址信息,如IP地址及端口。
8:CFP服务器发送响应消息(Response[Server Address]),将上传文件服务器的地址信息通知第一即时通信客户端。
9:第一即时通信客户端向上传文件服务器发送上传会话初始化(Initialize Session)信令,所述上传会话初始化信令中携带第一即时通信客户端的元数据,所述元数据包括接收方的标识(ID)和当前离线文件的属性信息。
当前离线文件的属性信息可以包括文件的消息摘要算法第五版(MD5)值,文件名和文件大小。当文件容量超过了2M,则还需包括文件的块列表信息,该块列表信息指示每个块的MD5值,以及块大小等。
10:上传文件服务器创建离线文件上传会话(CreateStoreSession).
11:上传文件服务器将所述元数据保存至离线文件业务服务所相应的数据库中(SaveTempUserFileInfo)。
进一步的,本方案还支持断点续传功能,这时,该方法还包括:上传文件服务器通过查询该上传文件服务器的缓存中所保存的文件数据判断当前离线文件是否属于断点续传,若是,将断点位置通知第一即时通信客户端,第一即时通信客户端从断点位置起上传当前离线文件的相应内容;若否,第一即时通信客户端上传当前离线文件的全部内容。
上传文件服务器查询该上传文件服务器的缓存中是否存在具有相同元数据的文件块来判断是否是属于断点续传,若存在,通过将缓存中的文件块的当前实际字节数(如字节偏移量值Offset)读出,得到断点位置。将断点位置的信息(该信息可包含在块列表信息中)写入应答信息中返回给客户端,告知客户端可以从文件块的哪个部分(由Offset值指示)读取字节流上传;若不存在,将缓存中文件块的当前字节数置零(即起始位置),则不需要断点续传操作,执行正常的离线文件上传过程,第一即时通信客户端上传当前离线文件的全部内容。
由上可见,对于上传流程来说,在文件上传过程中,有可能会碰到发送方取消上传的情况,或者断网、断线等极端的情况,在发送方中断上传之后,服务器侧会将缓存中的文件块结合发送方ID、文件ID、接收方ID存储在内存中的特定数据结构(如Dictionary,字典数据结构)中,保存时间的长短可以由服务器端的XML配置灵活决定;在下次上传相同文件的时候,服务器端根据发送方ID文件ID,接收方Id在缓存中查询到文件块,便直接发送当前的文件进度(也可以称为当前实际字节数,Offset)给接收方,以此为起点进行断点续传,这样发送方就不用在一次中断之后再次从零开始传,提高了资源的利用率,加快了文件的传输。
12:上传文件服务器向第一即时通信客户端发送应答消息。
该应答消息中可以携带块列表信息。
13:第一即时通信客户端向上传文件服务器发送数据上传(PostData信令)。
第一即时通信客户端按照所创建的离线文件上传会话,通过离线文件服务器将离线文件上传至FastDFS存储器并保存。
可以根据所述块文件容量配置将当前离线文件划分为多个文件块。第一即时通信客户端采用多线程的方式,按照预定容量的字节流,以文件块为单位,利用所创建的离线文件上传会话,通过离线文件服务器将离线文件上传至FastDFS存储器并保存。其中,所述预定容量的字节流为8K的字节流,所述块文件容量配置为2M。
13a:离线文件服务器将接收到的一个文件块的字节流先存储在缓存中(StoreDataBuffer),当一个文件块的传输完成后,则对文件块的MD5值进行校验以证明该文件块已经传输完毕没有错误,然后将该文件块传输至FastDFS存储器。
13b:离线文件服务器通过线程操作将传输完成的文件块写入FastDFS存储器(StoreFileChunk)。
14:离线文件服务器向第一即时通信客户端发送响应消息(Response),指示文件块上传成功。
15:当上传完成后,第一即时通信客户端向上传文件服务器发送会话结束(FinishSession)指令。
离线文件业务服务将当前离线文件的物理路径保存在相应的数据库中。
16:当第一即时通信客户端上传操作结束后,若上传文件服务器的缓存中还存在有文件块,将缓存中的存在的文件块的字节流都写入到FDFS中去(FlushFileFromBuffer),完成之后清空上传文件服务器的缓存。
17:通过线程调用操作将缓存中的文件块写入FDFS存储器(StoreFileChunk)。
18:本次上传文件成功,上传文件服务器移除会话(RemoveSession)。
19:上传文件服务器向第一即时通信客户端发送响应消息,告知第一即时通信客户端所上传的离线文件的ID,第一即时通信客户端将该离线文件的ID发送至系统中的相应设备,以使系统向第二即时通信客户端推送的离线文件接收通知中携带该离线文件的ID。
离线文件下载
第二即时通信客户端(也可表示为Client B)登录即时通信客户端后,即第二即时通信客户端上线后,收到系统推送的离线文件接收通知,该离线文件接收通知中携带需要下载的离线文件的ID。
1:Client B点击接收上述离线文件接收通知,向离线文件服务器发送Allocate请求信令,所述Allocate请求信令携带需要下载的离线文件的ID。
2:离线文件服务器根据上述Allocate请求信令,向Client B返回响应消息。该步骤的具体操作可以参见图3中的步骤5至8。
离线文件服务器通过离线文件业务服务在相应数据库中查询所分配的下载文件服务器的地址信息和当前离线文件的元数据,并通知第二即时通信客户端,所述地址信息包括下载文件服务器的IP地址及端口号,所述下载文件服务器为从多个离线文件服务器中选取的一个服务器。示例性的,图4中以下载文件服务器与该图中步骤1的离线文件服务器一致的情况进行了描述。
3:CFP服务器获取离线文件的元数据(GetUserFileInfo)。
CFP服务器通过CFBS,根据离线文件Id从相应数据库中查询出离线文件的元数据,该元数据可以包括文件MD5值,发送方ID,文件名称,创建时间,过期时间,当前状态,文件大小,以及块文件列表等,上述过期时间指示服务器侧可以保存离线文件的最长期限,即当超过过期时间后,服务器侧将删除该离线文件。
4:CFBS向CFP服务器返回离线文件元数据。
5:CFP服务器向Client B发送响应消息(Response[File ChunkList]),该响应消息中携带离线文件元数据,如携带块文件列表。
在此,本方案采用的处理方式CFP服务器直接将元数据转发至Client B,CFP服务器不对该元数据进行存储。
6:第二即时通信客户端通过HTTP连接向下载文件服务器发送下载会话初始化信令(InitilizeSession),请求建立离线文件下载会话。
通过该下载会话初始化信令向提交相关的信息,如块文件列表等。
7:下载文件服务器创建离线文件下载会话(CreateFetchSession)。
8:CFP服务器将当前离线文件的下载状态保存至CFBS所相应的数据库中(SaveFetchStarted),该下载状态指示正在下载。
9:CFP服务器从离线文件业务服务的相应数据库中获取当前离线文件的逻辑信息(GetLogicalFileInfo)。所述逻辑信息包括当前离线文件的元数据和物理路径。
10:离线文件业务服务通过响应消息将逻辑信息发送至CFP服务器。
11:CFP服务器将上述逻辑信息保存至缓存中(AddFileToSession)。
12:CFP服务器向第二即时通信客户端发送响应消息。
该响应消息可以向第二即时通信客户端确定块列表信息以及第二即时通信客户端应该开始下载文件的当前进度值。
本方案在接收方下载文件时也可以支持断点续传功能,相关操作可以参见上文的相关内容。
13:第二即时通信客户端向下载文件服务器发送数据下载(GetData)信令,以多线程方式向CFP服务器发起下载请求。
进一步的,第二即时通信客户端采用多线程的方式,按照预定容量的字节流,以文件块为单位,利用所创建的离线文件上传会话,通过下载文件服务器从FastDFS存储器中下载相应的离线文件;
其中,所述预定容量的字节流为8K的字节流,所述文件块的大小为2M。
13a:在每一个文件块的下载过程中,下载文件服务器先将整个文件块从FastDFS存储器读取出来保存至缓存中。
对每一个文件块,CFP服务器在开始时先获取整个文件块的字节流时,如以每次2M的形式从FastDFS存储器中读出整个文件块的字节流并存入CFP服务器的缓存中。
13b:CFP服务器以每次8K的形式从缓存中读取文件块的字节流(FetchByteStreamFrom Buffer)。
13c:CFP服务器向第二即时通信客户端发送响应消息,通过该响应消息以每次8K的形式将文件块的字节流发送至第二即时通信客户端,直至完成整个文件块的传输。
即在下载一个文件块时,除了起始时需要和FastDFS存储器交互之外,后续每次获取文件块字节流时都直接从内存中获取,不再访问FastDFS存储器以提高读取效率。
14:当下载完成后,第二即时通信客户端向下载文件服务器发送会话结束(FinishSession)指令。
15:下载文件服务器确认完成下载,保存文件已下载完成的状态(SaveFetchCompleted)。
16:下载文件服务器清理缓存(ClearFileFromBuffer)。
CFP服务器清理缓存,删除离线文件的相关信息。
17:下载文件服务器移除当前会话(RemoveSession)。
18:下载文件服务器向第二即时通信客户端发送响应消息,确认当前下载结束。
应当注意到,本方案中对上传/下载文件字节流采用了8K的限制以及对文件块采用了2M的限制,主要原因在于:对于传输文件字节流的数值,若太大的话,当网关不太稳定时,将会导致上传/下载速度急速降低,若太小的话,由于Http信令中本身会包含一些描述性信息,文件分得越碎,与文件本身无关的描述性信息越多,造成很多不必要的数据冗余,同时传输效率也会变低下。对于文件块大小的限制,主要从内存块管理的经验出发,在有很多文件流请求的情况下,文件块太大,可能会导致内存不太好申请,太小则会导致文件输入输出(IO)次数太多而影响传输速度。
并且,本方案的文件存储机制中采用FastDFS这种开源的轻量级文件存储解决方案,简化了文件存储管理流程,服务器侧只需要关注如何保存离线文件的元数据,如何处理上传、下载、续传、拒收、清理文件的流程。服务器侧调用FastDFS存储器的API对文件进行存储、获取,而不必考虑文件的具体存储位置,也不必考虑文件的备份与同步问题。
由上述可见,本发明实施例提供了一种新型的向离线状态的即时通信客户端传输文件的解决方案,弥补了现有即时通信技术中只能在通信双方同时在线时进行文件传输的缺陷,丰富了即时通信系统的功能,便利了用户的使用,提高了用户体验。
并且,本技术方案通过整体架构和传输流程的设置,能够快速实现离线文件的上传和下载。
本发明实施例三还提供了一种实现离线文件传输的系统,所述系统包括至少两个即时通信客户端、至少一个离线文件服务器和FastDFS存储器,所述即时通信客户端包括作为发送方的第一即时通信客户端和作为接收方的第二即时通信客户端,
所述第一即时通信客户端,用于当第二即时通信客户端处于离线状态时,与离线文件服务器建立HTTP连接,并通过所述HTTP连接将离线文件上传至离线文件服务器;
所述离线文件服务器,用于将接收到的离线文件传输至FastDFS存储器并保存;
所述第二即时通信客户端,用于在上线后,根据接收到的离线文件接收通知,与离线文件服务器建立HTTP连接,并通过离线文件服务器从FastDFS存储器下载得到相应的离线文件;
其中,所述离线文件服务器,还用于通过查询缓存中所保存的文件数据判断当前离线文件是否属于断点续传,若是,将断点位置通知第一即时通信客户端,第一即时通信客户端从断点位置起上传当前离线文件的相应内容;若否,第一即时通信客户端上传当前离线文件的全部内容;以及,
所述第二即时通信客户端,还用于以文件块为单位通过离线文件服务器下载相应的离线文件,在每一个文件块的下载过程中,离线文件服务器先将整个文件块从FastDFS存储器读取出来,然后按照预定容量的字节流将文件块传输至第二即时通信客户端。
本发明系统实施例中各单元和设备的具体工作方式可以参见本发明方法实施例。
由上述可见,本发明实施例提供了一种新型的向离线状态的即时通信客户端传输文件的解决方案,弥补了现有即时通信技术中只能在通信双方同时在线时进行文件传输的缺陷,丰富了即时通信系统的功能,便利了用户的使用,提高了用户体验。
并且,本技术方案通过整体架构和传输流程的设置,能够快速实现离线文件的上传和下载。
本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以软件产品的形式体现出来,该计算机软件产品可以存储在存储介质中,如ROM/RAM、磁碟、光盘等,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。
以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明保护的范围之内。
Claims (9)
1.一种实现离线文件传输的方法,其特征在于,所述方法包括:
当作为接收方的第二即时通信客户端处于离线状态时,作为发送方的第一即时通信客户端与离线文件服务器建立超文本传输协议HTTP连接,并通过所述HTTP连接将离线文件上传至离线文件服务器;
离线文件服务器将接收到的离线文件传输至高效分布式文件系统FastDFS存储器并保存;
第二即时通信客户端上线后,根据接收到的离线文件接收通知,与离线文件服务器建立HTTP连接;
第二即时通信客户端通过离线文件服务器从FastDFS存储器下载得到相应的离线文件;
其中,所述通过所述HTTP连接将离线文件上传至离线文件服务器包括:
第一即时通信客户端向离线文件服务器发送配置Allocate请求信令;
离线文件服务器通过离线文件业务服务在相应数据库中查询所分配的上传文件服务器的地址信息,并通知第一即时通信客户端,所述地址信息包括上传文件服务器的IP地址及端口号,所述上传文件服务器为从多个离线文件服务器中选取的一个服务器,所述上传文件服务器为上述与第一即时通信客户端建立HTTP连接的离线文件服务器,或者为不同于上述与第一即时通信客户端建立HTTP连接的离线文件服务器的另一离线文件服务器;
第一即时通信客户端向上传文件服务器发送上传会话初始化InitializeSession信令,所述上传会话初始化信令中携带第一即时通信客户端的元数据,所述元数据包括接收方的标识ID和当前离线文件的属性信息;
上传文件服务器创建离线文件上传会话,并将所述元数据保存至离线文件业务服务所相应的数据库中;
第一即时通信客户端向上传文件服务器发送数据上传PostData信令,按照所创建的离线文件上传会话,通过离线文件服务器将离线文件上传至FastDFS存储器并保存;
当上传完成后,第一即时通信客户端向上传文件服务器发送会话结束FinishSession指令,以及,离线文件业务服务将当前离线文件的物理路径保存在相应的数据库中。
2.根据权利要求1所述的方法,其特征在于,在通过所述HTTP连接将离线文件上传至离线文件服务器之前,所述方法还包括:
第一即时通信客户端向离线文件服务器发送查询Query指令,查询第一即时通信客户端的当前剩余空间;
离线文件服务器根据所述查询指令,从离线文件业务服务获取第一即时通信客户端的当前剩余空间容量,并通过查询响应发送至第一即时通信客户端;
第一即时通信客户端将当前剩余空间与当前离线文件进行比较,确认当前剩余空间的容量大于当前离线文件的容量后,启动当前离线文件的上传。
3.根据权利要求2所述的方法,其特征在于,
所述查询响应中还携带块文件容量配置;
根据所述块文件容量配置将当前离线文件划分为多个文件块,所述上传会话初始化信令中还携带有当前离线文件的块列表信息,所述当前离线文件的属性信息包含块列表信息;
第一即时通信客户端采用多线程的方式,按照预定容量的字节流,以文件块为单位,利用所创建的离线文件上传会话,通过离线文件服务器将离线文件上传至FastDFS存储器并保存;
其中,所述预定容量的字节流为8K的字节流,所述块文件容量配置为2M。
4.根据权利要求2或3所述的方法,其特征在于,在第一即时通信客户端向上传文件服务器发送数据上传PostData信令之前,所述方法还包括:
上传文件服务器通过查询缓存中所保存的文件数据判断当前离线文件是否属于断点续传,若是,将断点位置通知第一即时通信客户端,第一即时通信客户端从断点位置起上传当前离线文件的相应内容;若否,第一即时通信客户端上传当前离线文件的全部内容。
5.根据权利要求2所述的方法,其特征在于,所述第二即时通信客户端通过离线文件服务器从FastDFS存储器下载得到相应的离线文件包括:
第二即时通信客户端向离线文件服务器发送Allocate请求信令,所述Allocate请求信令携带需要下载的离线文件的ID,所述离线文件的ID从离线文件接收通知中获得;
离线文件服务器通过离线文件业务服务在相应数据库中查询所分配的下载文件服务器的地址信息和当前离线文件的元数据,并通知第二即时通信客户端,所述地址信息包括下载文件服务器的IP地址及端口号,所述下载文件服务器为从多个离线文件服务器中选取的一个服务器;
第二即时通信客户端向下载文件服务器发送下载会话初始化信令,请求建立离线文件下载会话;
下载文件服务器创建离线文件下载会话,并从离线文件业务服务的相应数据库中获取当前离线文件的逻辑信息,所述逻辑信息包括当前离线文件的元数据和物理路径;
第二即时通信客户端向下载文件服务器发送数据下载GetData信令,按照所创建的离线文件下载会话,通过下载文件服务器从FastDFS存储器中下载相应的离线文件;
当下载完成后,第二即时通信客户端向下载文件服务器发送会话结束FinishSession指令。
6.根据权利要求5所述的方法,其特征在于,
所述当前离线文件的元数据中包含块列表信息,
第二即时通信客户端采用多线程的方式,按照预定容量的字节流,以文件块为单位,利用所创建的离线文件下载会话,通过下载文件服务器从FastDFS存储器中下载相应的离线文件;
其中,所述预定容量的字节流为8K的字节流,所述文件块的大小为2M。
7.根据权利要求6所述的方法,其特征在于,
在每一个文件块的下载过程中,下载文件服务器先将整个文件块的字节流从FastDFS存储器读取出来保存至缓存中,然后从缓存中每次读取预定容量的字节流并发送至第二即时通信客户端,直至该文件块下载完毕。
8.根据权利要求6所述的方法,其特征在于,所述方法还包括:
当FastDFS存储器保存的离线文件超出预定时间后,FastDFS存储器删除该离线文件,离线文件业务服务删除相应数据库中该离线文件所关联的数据。
9.一种实现离线文件传输的系统,其特征在于,所述系统包括至少两个即时通信客户端、至少一个离线文件服务器和FastDFS存储器,所述即时通信客户端包括作为发送方的第一即时通信客户端和作为接收方的第二即时通信客户端,
所述第一即时通信客户端,用于当第二即时通信客户端处于离线状态时,与离线文件服务器建立HTTP连接,并通过所述HTTP连接将离线文件上传至离线文件服务器;
所述离线文件服务器,用于将接收到的离线文件传输至FastDFS存储器并保存;
所述第二即时通信客户端,用于在上线后,根据接收到的离线文件接收通知,与离线文件服务器建立HTTP连接,并通过离线文件服务器从FastDFS存储器下载得到相应的离线文件;
其中,所述离线文件服务器,还用于通过查询缓存中所保存的文件数据判断当前离线文件是否属于断点续传,若是,将断点位置通知第一即时通信客户端,第一即时通信客户端从断点位置起上传当前离线文件的相应内容;若否,第一即时通信客户端上传当前离线文件的全部内容;以及,
所述第二即时通信客户端,还用于以文件块为单位通过离线文件服务器下载相应的离线文件,在每一个文件块的下载过程中,离线文件服务器先将整个文件块从FastDFS存储器读取出来,然后按照预定容量的字节流将文件块传输至第二即时通信客户端;
其中,所述第一即时通信客户端具体用于:
向离线文件服务器发送配置Allocate请求信令;
离线文件服务器通过离线文件业务服务在相应数据库中查询所分配的上传文件服务器的地址信息,并通知第一即时通信客户端,所述地址信息包括上传文件服务器的IP地址及端口号,所述上传文件服务器为从多个离线文件服务器中选取的一个服务器,所述上传文件服务器为上述与第一即时通信客户端建立HTTP连接的离线文件服务器,或者为不同于上述与第一即时通信客户端建立HTTP连接的离线文件服务器的另一离线文件服务器;
第一即时通信客户端向上传文件服务器发送上传会话初始化InitializeSession信令,所述上传会话初始化信令中携带第一即时通信客户端的元数据,所述元数据包括接收方的标识ID和当前离线文件的属性信息;
上传文件服务器创建离线文件上传会话,并将所述元数据保存至离线文件业务服务所相应的数据库中;
第一即时通信客户端向上传文件服务器发送数据上传PostData信令,按照所创建的离线文件上传会话,通过离线文件服务器将离线文件上传至FastDFS存储器并保存;
当上传完成后,第一即时通信客户端向上传文件服务器发送会话结束FinishSession指令,以及,离线文件业务服务将当前离线文件的物理路径保存在相应的数据库中。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201110183229.XA CN102355426B (zh) | 2011-06-30 | 2011-06-30 | 实现离线文件传输的方法和系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201110183229.XA CN102355426B (zh) | 2011-06-30 | 2011-06-30 | 实现离线文件传输的方法和系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102355426A CN102355426A (zh) | 2012-02-15 |
CN102355426B true CN102355426B (zh) | 2015-01-14 |
Family
ID=45578923
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201110183229.XA Active CN102355426B (zh) | 2011-06-30 | 2011-06-30 | 实现离线文件传输的方法和系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102355426B (zh) |
Families Citing this family (36)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103259819B (zh) * | 2012-02-20 | 2017-12-15 | 腾讯科技(深圳)有限公司 | 文件共享的方法及系统 |
CN103297449B (zh) * | 2012-02-24 | 2017-12-12 | 腾讯科技(深圳)有限公司 | 一种文件传输方法、即时通信终端及系统 |
CN102638418A (zh) * | 2012-03-31 | 2012-08-15 | 上海量明科技发展有限公司 | 一种即时通信中数据传输的方法、客户端和系统 |
CN103841159B (zh) * | 2012-11-26 | 2017-04-19 | 北京新媒传信科技有限公司 | 一种离线文件传输系统和方法 |
CN103118120A (zh) * | 2013-02-17 | 2013-05-22 | 北京量子伟业时代信息技术有限公司 | 一种智能离线数据上传系统 |
CN103220361A (zh) * | 2013-04-23 | 2013-07-24 | 深圳市元征科技股份有限公司 | 一种断点续传的方法和具有断点续传功能的诊断设备 |
CN103401914A (zh) * | 2013-07-26 | 2013-11-20 | 浪潮电子信息产业股份有限公司 | 一种文件上传断点续传的方法 |
CN103546549B (zh) * | 2013-10-12 | 2017-12-12 | 深圳Tcl新技术有限公司 | 终端离线数据共享的方法及系统 |
CN104660484B (zh) * | 2013-11-21 | 2017-08-22 | 腾讯科技(深圳)有限公司 | 一种用于即时通讯客户端的数据传输方法以及装置 |
CN105763650B (zh) * | 2013-11-26 | 2019-08-02 | 北京奇虎科技有限公司 | 一种离线文件传输的方法、系统、终端设备以及服务器 |
CN105978956B (zh) * | 2013-11-26 | 2019-03-08 | 北京奇虎科技有限公司 | 一种离线文件传输的方法、系统、终端设备以及服务器 |
CN103916310A (zh) * | 2014-03-28 | 2014-07-09 | 北京奇虎科技有限公司 | 发送即时通信消息的方法、即时通信客户端和服务器 |
CN105794148A (zh) * | 2014-06-27 | 2016-07-20 | 北京新媒传信科技有限公司 | 一种数据发送/接收方法、装置、智能终端及系统 |
CN105530162A (zh) * | 2014-10-21 | 2016-04-27 | 中兴通讯股份有限公司 | 离线消息处理方法及装置 |
CN105991406A (zh) * | 2015-02-12 | 2016-10-05 | 深圳中兴网信科技有限公司 | 一种群组消息的发送方法和系统 |
CN104735094B (zh) * | 2015-04-21 | 2018-02-27 | 南京伍安信息科技有限公司 | 基于信息分离的数据安全传输系统及方法 |
CN106941451B (zh) * | 2016-01-04 | 2019-10-22 | 中国科学院声学研究所 | 一种基于网络感知和覆盖率阈值矩阵的文件智能缓存方法 |
CN107239239A (zh) * | 2016-03-28 | 2017-10-10 | 平安科技(深圳)有限公司 | 数据传输方法和系统 |
CN105978949A (zh) * | 2016-04-27 | 2016-09-28 | 乐视控股(北京)有限公司 | 离线数据上传方法及装置 |
CN106685804A (zh) * | 2016-12-29 | 2017-05-17 | 北京奇虎科技有限公司 | 发送离线消息的方法及装置 |
CN106598872A (zh) * | 2017-01-03 | 2017-04-26 | 百融(北京)金融信息服务股份有限公司 | 智能设备应用程序处理系统和方法 |
CN108933805A (zh) * | 2017-05-26 | 2018-12-04 | 武汉斗鱼网络科技有限公司 | 一种文件传输方法及系统 |
CN107222499A (zh) * | 2017-07-04 | 2017-09-29 | 四川云物益邦科技有限公司 | 基于离线存储技术的文件管理方法 |
CN109309696B (zh) * | 2017-07-27 | 2021-09-17 | 腾讯科技(深圳)有限公司 | 文件夹发送方法、发送方、接收方以及存储介质 |
CN107463657B (zh) * | 2017-07-28 | 2018-08-17 | 腾讯科技(深圳)有限公司 | 文件操作方法及终端 |
CN107483605B (zh) * | 2017-08-29 | 2020-12-04 | 北京小米移动软件有限公司 | 文件下载方法及装置、存储介质 |
CN110022329B (zh) * | 2018-01-08 | 2022-03-11 | 腾讯科技(深圳)有限公司 | 文件传输方法、装置、计算机可读存储介质及计算机设备 |
CN109491976A (zh) * | 2018-11-23 | 2019-03-19 | 郑州云海信息技术有限公司 | 一种存储数据解析方法、装置及相关设备 |
CN111857534A (zh) * | 2019-04-24 | 2020-10-30 | 北京嘀嘀无限科技发展有限公司 | 一种数据传输方法、数据存储服务器及数据存储系统 |
CN110198351A (zh) * | 2019-05-29 | 2019-09-03 | 深圳前海微众银行股份有限公司 | 离线消息的存储方法、装置、服务端及可读存储介质 |
CN110830367A (zh) * | 2019-11-19 | 2020-02-21 | 北京蜜莱坞网络科技有限公司 | 即时通讯的数据交互方法、装置、设备及介质 |
CN111405020B (zh) * | 2020-03-10 | 2023-03-31 | 山东汇贸电子口岸有限公司 | 基于消息队列和fastDFS微服务架构的异步文件导出方法及系统 |
CN111404959A (zh) * | 2020-03-26 | 2020-07-10 | 中车青岛四方车辆研究所有限公司 | 一种实现传输非实时离线文件的方法及系统 |
CN111866120A (zh) * | 2020-07-17 | 2020-10-30 | 合肥移瑞通信技术有限公司 | 文件事务传输的方法与系统、可读存储介质、服务器 |
CN112968935B (zh) * | 2021-01-29 | 2023-02-17 | 北京字跳网络技术有限公司 | 数据传输方法、装置、终端和存储介质 |
CN114338646B (zh) * | 2021-11-29 | 2024-06-21 | 王建冬 | 文件交互传输方法、装置、设备及存储介质 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101106542A (zh) * | 2007-08-20 | 2008-01-16 | 北京亿企通信息技术有限公司 | 一种在即时通信工具中传输文件的方法及系统 |
CN101170523A (zh) * | 2007-12-05 | 2008-04-30 | 腾讯科技(深圳)有限公司 | 文件传输系统、方法以及文件中转决策服务器 |
CN101184055A (zh) * | 2007-12-11 | 2008-05-21 | 腾讯科技(深圳)有限公司 | 一种离线文件的发送、接收、传输方法及装置 |
CN101420389A (zh) * | 2007-10-25 | 2009-04-29 | 中兴通讯股份有限公司 | 一种文件传送系统及方法 |
-
2011
- 2011-06-30 CN CN201110183229.XA patent/CN102355426B/zh active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101106542A (zh) * | 2007-08-20 | 2008-01-16 | 北京亿企通信息技术有限公司 | 一种在即时通信工具中传输文件的方法及系统 |
CN101420389A (zh) * | 2007-10-25 | 2009-04-29 | 中兴通讯股份有限公司 | 一种文件传送系统及方法 |
CN101170523A (zh) * | 2007-12-05 | 2008-04-30 | 腾讯科技(深圳)有限公司 | 文件传输系统、方法以及文件中转决策服务器 |
CN101184055A (zh) * | 2007-12-11 | 2008-05-21 | 腾讯科技(深圳)有限公司 | 一种离线文件的发送、接收、传输方法及装置 |
Also Published As
Publication number | Publication date |
---|---|
CN102355426A (zh) | 2012-02-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102355426B (zh) | 实现离线文件传输的方法和系统 | |
CN103078881B (zh) | 网络资源下载信息的分享控制系统和方法 | |
CN104221003B (zh) | 利用异步数据词典在多租户共享的基础设施中的基于流的重复数据删除 | |
CN103731451B (zh) | 一种文件上传的方法及系统 | |
CN104980482B (zh) | 文件发送方法及装置、文件接收方法及装置 | |
CN107483627A (zh) | 一种文件分发、下载方法、分发服务器、客户端及系统 | |
CN101395838A (zh) | 数据同步方法、系统和装置 | |
US9442925B2 (en) | Regulated texting solution for mobile devices | |
CN102708192B (zh) | 一种文档共享的方法及系统、设备 | |
CN110263001B (zh) | 文件管理方法、装置、系统、设备及计算机可读存储介质 | |
CN110703980A (zh) | 一种文件传输方法及装置 | |
CN101662454A (zh) | 互联网中图像处理的方法、装置和系统 | |
CN103220308B (zh) | 一种文件下载方法、装置及系统 | |
US20130163610A1 (en) | Packet forwarding structure and method for supporting network based content caching of aggregate contents | |
CN102014145A (zh) | 文件传输安全管控系统及方法 | |
CN104618444A (zh) | 一种基于反向代理服务器处理请求的方法和装置 | |
CN102984277B (zh) | 防止恶意连接的系统和方法 | |
CN109525622A (zh) | 分片资源id的生成方法、资源分享方法,装置及电子设备 | |
CN108134811B (zh) | 目标文件分发或下载的方法、装置和系统 | |
CN102857547B (zh) | 分布式缓存的方法及设备 | |
CN105074688B (zh) | 使用对等节点图的基于流的数据去重复 | |
CN105893429A (zh) | 用于优化web缓存的方法及系统 | |
CN109213955B (zh) | 数据处理方法及相关设备 | |
CN110519656A (zh) | 自适应流媒体的播放方法、系统以及服务器 | |
CN104283763A (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 | ||
CP02 | Change in the address of a patent holder |
Address after: Room 818, 8 / F, 34 Haidian Street, Haidian District, Beijing 100080 Patentee after: BEIJING ULTRAPOWER SOFTWARE Co.,Ltd. Address before: 100089 Beijing city Haidian District wanquanzhuang Road No. 28 Wanliu new building A block 5 layer Patentee before: BEIJING ULTRAPOWER SOFTWARE Co.,Ltd. |
|
CP02 | Change in the address of a patent holder |