文件传输方法、装置及网络KTV系统与流程

文件传输方法、装置及网络ktv系统
技术领域
1.本技术涉及计算机互联网技术领域，尤其是一种文件传输方法、装置、ktv盒子、计算机设备及计算机可读存储介质。


背景技术：

2.目前，在很多场合中，音视频娱乐设备得到广泛使用，以常用的ktv盒子来说，ktv盒子是集成点歌、调音等功能的专用设备，可以通过电视机等显示设备连接使用，从而为用户提供了家庭ktv娱乐体验。
3.随着网络技术发展，ktv盒子结合网络功能实现网络ktv功能，可以进行在线唱歌，包括个人对唱、多人合唱、直播个人唱歌或者演唱会等等。在使用过程中，ktv盒子客户端的需要与服务器端的歌曲库进行同步更新，或者与其他ktv盒子客户端进行歌曲文件的交互。
4.现有技术中，在进行在线唱歌时，ktv盒子的客户端也需要与其他ktv盒子进行歌曲文件互传分享，唱歌音视频互动传输等等；而当前文件传输主要是采用webrtc的p2p技术，即基于webrtc的mediachannel来传输音视频文件，这种技术传输效率和安全性方面都存在不足。


技术实现要素：

5.为了解决上述技术不足，本技术提供一种文件传输方法、装置、ktv盒子、计算机设备及计算机可读存储介质，提高了客户端之间歌曲文件传输效率和安全性。
6.一种文件传输方法，包括：
7.基于rtc协议建立第一客户端与第二客户端之间的数据通道；
8.从所述第一客户端获取歌曲文件，利用私有协议对所述歌曲文件封装后得到传输文件协议包，通过所述数据通道发送至第二客户端；其中，所述私有协议是基于rtc协议且承载于所述数据通道上；
9.获取所述第二客户端接收的rtc数据包，从所述rtc数据包中提取出传输文件协议包，并依据所述私有协议解析所述传输文件协议包得到对应的歌曲文件。
10.在一个实施例中，基于rtc协议建立第一客户端与第二客户端之间的数据通道，包括：
11.由第一客户端向信令服务器发送连接请求，所述信令服务器将所述连接请求转发至所述第二客户端；
12.由第二客户端响应所述连接请求，向所述信令服务器发送连接确认信息，所述信令服务器将连接确认信息转发至所述第一客户端；
13.由第一客户端向信令服务器发送offer sdp，所述信令服务器将所述offer sdp转发至所述第二客户端；
14.由第二客户端响应所述offer sdp生成answer sdp并发送至所述信令服务器，所述信令服务器将answer sdp转发至所述第一客户端，建立rtc连接的数据通道。
15.在一个实施例中，从所述第一客户端获取歌曲文件之前，还包括：
16.由所述第一客户端通过所述私有协议向所述第二客户端发送唱歌邀请及演唱歌曲信息；
17.通过所述第二客户端接收所述唱歌邀请，并在对所述演唱歌曲信息进行确认后，向所述第一客户端返回共享歌曲请求；
18.由所述第一客户端响应所述共享歌曲请求在本地查找所述演唱歌曲信息对应的歌曲文件，并通过所述数据通道发送到所述第二客户端；
19.其中，所述第二客户端收到所述歌曲文件后存储在本地。
20.在一个实施例中，从所述第一客户端获取歌曲文件之前，还包括：
21.由所述第一客户端通过所述私有协议向所述第二客户端发送唱歌邀请及演唱歌曲信息；
22.通过所述第二客户端接收所述唱歌邀请，并在根据所述演唱歌曲信息进行本地查询获取对应的歌曲文件，并向所述第一客户端返回共享歌曲请求；
23.由所述第二客户端接收所述第一客户端响应所述共享歌曲请求的确认信息，并通过所述数据通道将所述歌曲文件发送到所述第一客户端；其中，所述第一客户端收到所述歌曲文件后存储在本地。
24.在一个实施例中，所述的文件传输方法，还包括：
25.由第一客户端采集本地话筒的第一音频流和摄像头的第一视频流，基于所述私有协议封装成第一音视频包，通过所述数据通道传输到所述第二客户端；其中，所述第二客户端依据所述私有协议从所述第一音视频包中解析出第一音频和第一视频；
26.以及
27.由第二客户端采集本地话筒的第二音频流和摄像头的第二视频流，基于所述私有协议封装成第二音视频包，通过所述数据通道传输到所述第一客户端；其中，所述第一客户端依据所述私有协议从所述第二音视频包中解析出第二音频和第二视频。
28.在一个实施例中，所述的文件传输方法，还包括：
29.由第一客户端向所述第二客户端发送加密信息；同时第一客户端利用所述加密信息对所述第一音频流和第一视频流进行加密，得到第一加密音视频包；在第一加密音视频包发送到第二客户端后，由所述第二客户端依据所述加密信息对所述第一加密音视频包进行解密；
30.以及
31.由第二客户端向所述第一客户端发送加密信息；同时第二客户端利用所述加密信息对所述第二音频流和第二视频流进行加密，得到第二加密音视频包；在第二加密音视频包发送到第一客户端后，由所述第一客户端依据所述加密信息对所述第二加密音视频包进行解密；
32.其中，所述加密信息包括加密方式、加密算法和加密解密用密钥。
33.在一个实施例中，所述的文件传输方法，还包括：对所述加密信息的加密方式、加密算法和加密解密用密钥进行动态更新。
34.在一个实施例中，所述加密算法包括aes加密算法、des加密算法和/或异或加密算法。
35.在一个实施例中，所述加密方法包括：
36.对音视频数据进行全加密；
37.对音视频数据进行部分加密
38.和/或
39.对所述传输文件协议包的数据字段进行选择性加密；
40.其中，所述音视频数据包括第一音视频和第二音视频。
41.在一个实施例中，在对唱模式中，所述加密方法包括：采用音视频数据全加密的方式和传输文件协议包的数据字段全加密的方式；
42.在多人合唱模式中，所述加密方法包括：采用对视频数据的关键帧i帧加密和传输文件协议包的数据字段部分加密的方式；
43.或者
44.在直播模式和个人演唱会模式下，所述加密方法包括：采用对音视频部分加密和传输文件协议包的数据字段部分加密方式，或者无加密方式。
45.在一个实施例中，所述私有协议包括：
46.协议头标识：用于区分数据流中每条消息起始位置和终止位置；
47.协议版本号：用于向后兼容；
48.数据加密方式：标识是否启用加密及其加密方式和标识加密算法；
49.数据类型：标记数据类型，所述类型包括：视频数据、音频数据、文本数据、歌曲文件、加密解密用密钥；
50.数据长度：标识有效负载数据的长度；
51.数据：存放消息内容；
52.crc校验：用于验证消息完整性。
53.在一个实施例中，所述协议头标识的长度为2byte，所述协议版本号的长度为1byte，所述数据加密方式的长度为1byte，所述数据类型的长度为1byte，所述数据长度的长度为4byte，所述crc校验的长度为4byte。
54.一种文件传输装置，包括：
55.通道连接单元，用于基于rtc协议建立第一客户端与第二客户端之间的数据通道；
56.协议发送单元，用于从所述第一客户端获取歌曲文件，利用私有协议对所述歌曲文件封装后得到传输文件协议包，通过所述数据通道发送至第二客户端；其中，所述私有协议是基于rtc协议且承载于所述数据通道上；
57.协议解析单元，用于获取所述第二客户端接收的rtc数据包，从所述rtc数据包中提取出传输文件协议包，并依据所述私有协议解析所述传输文件协议包得到对应的歌曲文件。
58.一种网络ktv系统，包括：多个通过网络连接的ktv盒子；其中，所述ktv盒子中的至少一者对应包括上述的第一客户端，以及至少一者对应包括上述的第二客户端。
59.一种计算机设备，其包括：
60.一个或多个处理器；
61.存储器；
62.一个或多个应用程序，其中所述一个或多个应用程序被存储在所述存储器中并被
配置为由所述一个或多个处理器执行，所述一个或多个程序配置用于：执行上述的文件传输方法。
63.一种计算机可读存储介质，所述存储介质存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行上述的文件传输方法。
64.本技术的技术方案，具有如下有益效果：
65.在基于rtc协议基础上，建立两个客户端之间的数据通道连接，利用数据通道用来载入私有协议的数据包传输音视频流媒体信息，实现不同终端之间的跨平台通信，提高了传输效率；同时，基于数据通道保护了客户端的个人隐私，也提升了文件传输的安全性。
66.进一步的，采用了创新的加密方案，降低非法截获加密音视频包后被破解的几率，增加了破解难度，提高了传输文件的安全性；另外，在充分兼顾系统消耗基础上，保证传输文件的安全性能。
67.进一步的，在现有webrtc标准协议基础上提供了创新的wktp私有协议，能够增加传输安全性，增加破解难度；同时，具有良好的扩展性，应用于其他非webrtc客户端上传输时也具有良好效果。
68.本技术附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本技术的实践了解到。
附图说明
69.本技术上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：
70.图1是一个示例的文件传输方法的硬件环境图；
71.图2是一个实施例的文件传输方法流程图；
72.图3是建立数据通道的流程图；
73.图4是基于rtc协议的私有协议示意图；
74.图5是一个示例的唱歌过程中的文件传输方法流程图；
75.图6是另一个示例的唱歌过程中的文件传输方法流程图；
76.图7是一个示例的传输文件的加解密流程图；
77.图8是一个示例的私有协议的结构图；
78.图9是一个实施例的文件传输装置的结构示意图。
具体实施方式
79.下面详细描述本技术的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本技术，而不能解释为对本技术的限制。
80.本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本技术的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作。
81.参考图1所示，图1是一个示例的文件传输方法的硬件环境图，图中所述网络中，有多个客户端接入到网络中，如客户端1
‑
n，n≥2，各个客户端可以通过rtc协议进行互联，并能够rtc协议与信令服务器进行连接，示例性的，图中所述的客户端可以是指ktv盒子的客户端；本技术的文件传输方案，主要是应用于客户端上，实现不同的客户端之间的歌曲文件传输功能。
82.下面对本技术的文件传输方法实施例进行描述。
83.参考图2所示，图2是一个实施例的文件传输方法流程图，包括：
84.s10，基于rtc协议建立第一客户端与第二客户端之间的data channel数据通道。
85.此步骤中，基于rtc(real
‑
time communications，实时通信)协议方式，在第一客户端与第二客户端之间建立实时通信连接；在本实施例中，以webrtc(web real
‑
time communication，源自网页即时通信)协议为例进行阐述。
86.对于建立第一客户端与第二客户端之间的data channel数据通道的技术方案，参考图3所示，图3是建立data channel数据通道的流程图，具体可以如下：
87.s101，由第一客户端向信令服务器发送连接请求，所述信令服务器将所述连接请求转发至所述第二客户端。
88.s102，由第二客户端响应所述连接请求，向所述信令服务器发送连接确认信息，所述信令服务器将连接确认信息转发至所述第一客户端。
89.s103，由第一客户端向信令服务器发送offer sdp，所述信令服务器将所述offer sdp转发至所述第二客户端。
90.s104，由第二客户端响应所述offer sdp生成answer sdp并发送至所述信令服务器，所述信令服务器将answer sdp转发至所述第一客户端，建立rtc连接的data channel数据通道。
91.s20，从所述第一客户端获取歌曲文件，利用私有协议对所述歌曲文件封装后得到传输文件协议包，通过所述data channel数据通道发送至第二客户端；其中，所述私有协议是基于rtc协议且承载于所述data channel数据通道上。
92.此步骤中，第一客户端获取到需要传输的歌曲文件，利用私有协议对歌曲文件封装后得到传输文件协议包，再通过data channel数据通道发送至第二客户端。
93.在此处，本实施例的方案定义了私有协议，其中该私有协议是基于rtc协议且承载于data channel数据通道上。
94.具体的，参考图4所示，图4是基于rtc协议的私有协议示意图；如图中，实线框内为rtc协议的协议栈，本实施例的私有协议通过在承载于data channel数据通道上，为了便于描述，自定义名字为“wktp协议”(下文同)；通过上述协议栈可以看出，本实施例的技术方案利用data channel数据通道用来载入私有协议的数据包来传输歌曲文件等音视频流媒体信息。
95.s30，获取所述第二客户端接收的rtc数据包，从所述rtc数据包中提取出传输文件协议包，并依据所述私有协议解析所述传输文件协议包得到对应的歌曲文件。
96.此步骤中，第二客户端基于rtc协议，对接收的rtc数据包进行解析，从而得到data channel数据通道中载入的传输文件协议包，然后基于私有协议对传输文件协议包进行解析，从而得到对应的歌曲文件，从而实现了不同客户端之间的歌曲文件传输。
97.综上所述，通过上述协议栈可以看出，本实施例的技术方案，在基于rtc协议基础上，将通常用于传输文本信息、控制信息以及指令等；而本实施例通过利用data channel数据通道用来载入私有协议的数据包传输音视频流媒体信息，从而可以在原有webrtc协议基础上，实现不同终端之间的跨平台通信，提高了传输效率；同时，基于data channel数据通道保护了客户端的个人隐私，也提升了文件传输的安全性。
98.为了更加清晰本技术技术方案，下面结合几种场合中应用实施例进行阐述。
99.本技术的技术方案，可以应用于在对唱模式，在多人合唱模式，在直播模式和个人演唱会模式等场景，下面实施例将就上述各种模式下进行唱歌时，歌曲文件的传输方案进行实施例描述。
100.据此，参考图5所示，图5是一个示例的唱歌过程中的文件传输方法流程图，可以包括如下步骤：
101.s201，第一客户端通过wktp协议向第二客户端发送唱歌邀请及演唱歌曲信息；其中，唱歌邀请可以是对唱要求，如果是多个客户端进行合唱，则各个客户端之间可以进行相互邀请。
102.s202，第二客户端接收唱歌邀请，并在对演唱的歌曲信息进行确认；具体的，确认过程主要是查询本地歌曲库是否存在该歌曲信息对应的歌曲文件。
103.s203，第二客户端确认后通过wktp协议向第一客户端返回共享歌曲请求；具体的，第二客户端查询本地发现没有对应的歌曲文件，发出共享歌曲请求。
104.s204，第一客户端响应共享歌曲请求在本地查找演唱歌曲信息对应的歌曲文件；具体地，第一客户端在本地查询到保存的该歌曲文件与第二客户端进行共享。
105.s205，第一客户端通过wktp协议将歌曲文件发送到第二客户端，与第二客户端进行共享。
106.s206，第二客户端收到歌曲文件后存储在本地。
107.需要说明的是，上述过程中第一客户端与第二客户端之间是通过wktp协议在data channel数据通道上进行通信。
108.另外，参考图6所示，图6是另一个示例的唱歌过程中的文件传输方法流程图，可以包括如下步骤：
109.s301，第一客户端通过wktp协议向第二客户端发送唱歌邀请及演唱歌曲信息；
110.s302，第二客户端接收唱歌邀请及演唱歌曲信息，根据演唱歌曲信息进行本地查询获取对应的歌曲文件；
111.s303，第二客户端通过wktp协议向第一客户端返回共享歌曲请求；
112.s304，第一客户端响应共享歌曲请求，并通过wktp协议向第二客户端返回确认信息；
113.s305，第二客户端通过wktp协议向第一客户端发送歌曲文件；
114.s306，第一客户端收到歌曲文件后存储在本地。
115.同理，上述过程中第一客户端与第二客户端之间是通过wktp协议在data channel数据通道上进行通信。
116.上述实施例的技术方案中，基于wktp协议在第一客户端与第二客户端之间的data channel数据通道上进行通信，使得两个客户端之间的文件传输效率更高，且更具安全性；
两个客户端的用户就可以快速安全地得到歌曲文件，即可进行网络对唱、合唱、直播或演唱会等。
117.在网络唱歌过程中，第一客户端与第二客户端之间进一步通过实时采集的音频流和视频流进行交互，从而可以在不同两个客户端上分别合成出实施mv效果；据此，在进行歌曲文件交互传输后，本实施例还提供进行音视频流的交互传输方案。
118.在一个实施例中，所述的文件传输方法还包括：
119.(1)第一客户端采集本地话筒的第一音频流和摄像头的第一视频流，基于wktp协议封装成第一音视频包，通过wktp协议在data channel数据通道上传输到第二客户端；然后第二客户端依据wktp协议从所述第一音视频包中解析出第一音频和第一视频。
120.(2)第二客户端采集本地话筒的第二音频流和摄像头的第二视频流，基于wktp协议封装成第二音视频包，通过wktp协议在data channel数据通道上传输到第一客户端；然后第一客户端依据wktp协议从所述第二音视频包中解析出第二音频和第二视频。
121.上述实施例的方案，主要是在唱歌过程中，同时将第一客户端和第二客户端实时获取的音视频数据，通过wktp协议在data channel数据通道上传输到对方的客户端上，从而实现了实时交互过程，由于实时交互对于时延要求较高，因此，通过本实施例提供的wktp协议在data channel数据通道上传输方案，将第一客户端和第二客户端都可以快速地获取到对方的音视频数据，并可以分别在两个客户端上进行合成mv歌曲文件，从而可以提高用户应用体验。
122.为了进一步提高传输安全性，本技术提供对于传输文件进行加密的实施例。对于加密内容可以包括传输的歌曲文件，主要是针对于第一客户端与第二客户端之间交互的音视频数据进行加密。
123.据此，在一个实施例中，本技术的文件传输方法，还可以包括如下：
124.(1)第一客户端向第二客户端发送加密信息；同时第一客户端利用加密信息对第一音频流和第一视频流进行加密，得到第一加密音视频包；然后发送到第二客户端，第二客户端依据加密信息对第一加密音视频包进行解密；其中，加密信息包括加密方式、加密算法和加密解密用密钥等等。
125.(2)第二客户端向第一客户端发送加密信息；同时第二客户端利用加密信息对第二音频流和第二视频流进行加密，得到第二加密音视频包；然后发送到第一客户端，第一客户端依据加密信息对第二加密音视频包进行解密；其中，加密信息包括加密方式、加密算法和加密解密用密钥等。
126.本实施例中，加密算法可以采用aes加密算法、des加密算法、异或加密算法等等。优选的，在加密过程中，对加密信息的加密方式、加密算法和加密解密用密钥进行动态更新；例如，通过每次发送时随机采用一种加密方式、加密算法和加密解密用密钥，由此，降低非法截获加密音视频包后被破解的几率，增加了破解难度，提高了传输文件的安全性。
127.在一个实施例中，为了降低系统在加密解密过程中的系统消耗，提高加密使用效果，本实施例在充分兼顾系统消耗基础上，设计了如下加密传输方案。
128.具体的，对于加密方法，可以包括对音视频数据进行全加密；对音视频数据进行部分加密；对所述传输文件协议包的数据字段进行选择性加密等；其中，所述音视频数据包括第一音视频和第二音视频。
129.优选的，对于加密方案，可以应用如下：
130.(1)在对唱模式中，所述加密方法包括：采用音视频数据全加密的方式和传输文件协议包的数据字段全加密的方式；具体的，此模式下，考虑到安全性最高，因此采用全部加密方式，确保双方隐私。
131.(2)在多人合唱模式中，所述加密方法包括：采用对视频数据的关键帧i帧加密和传输文件协议包的数据字段部分加密的方式；具体的，由于客户端连接较多，为缓解终端系统解密压力，采取部分关键帧加密和部分传输文件协议包的数据字段加密的技术方案，在维持较低系统消耗基础上，充分确保了关键信息安全。
132.(3)在直播模式和个人演唱会模式下，所述加密方法包括：采用对音视频部分加密和传输文件协议包的数据字段部分加密方式，或者无加密方式；具体的，该模式下，对于安全性要求较低，据此，可以根据实际需要来选择加密，甚至也可以不进行加密。
133.参考图7所示，图7是一个示例的传输文件的加解密流程图；图中以发起对唱为例，在第一客户端向第二客户端发起对唱后，第二客户端返回响应请求进入对唱模式。
134.在第一客户端一侧，其处理过程如下：
135.a、将加密方式、加密算法、加密解密用密钥key等加密信息发送到第二客户端。
136.b、采集音视频数据，分别对音视频数据进行加密后打包，通过wktp协议生成wktp协议包(即传输文件协议包)，对wktp协议包进行选择性加密，得到加密音视频包。
137.c、将加密音视频包发送到第二客户端。
138.在第二客户端一侧，其处理过程相反，包括如下：
139.d、解析并利用加密信息解密对wktp协议包；
140.e、解析并分别解密音频数据和视频数据；
141.f、播放音视频数据。
142.需要说明的是，第二客户端加密音视频数据发送至第一客户端的处理过程，与上述流程基本原理相同，在此不再赘述。
143.为了更加优化本技术的技术方案，以取得更好的技术效果，本技术还提供了对于私有协议具体结构的若干实施例。
144.在一个实施例中，参考图8所示，图8是一个示例的私有协议的结构图，所述私有协议的结构包括如下：
145.协议头标识：用于区分数据流中每条消息起始位置和终止位置，优选的，长度为2byte；
146.协议版本号：用于向后兼容，优选的，长度为1byte；
147.数据加密方式：标识是否启用加密及其加密方式和标识加密算法，优选的，长度为1byte；
148.数据类型：标记数据类型，所述类型包括：视频数据、音频数据、文本数据、歌曲文件、加密解密用密钥，优选的，长度为1byte；
149.数据长度：标识有效负载数据的长度，优选的，长度为4byte；
150.数据：存放消息内容，数据长度为数据内容长度；
151.crc校验：用于验证消息完整性，优选的，长度为4byte。
152.为了更加清晰本实施例的wktp协议的使用，下面以第一客户端要发一段视频数据
到第二客户端为例阐述发送和解析过程。
153.对于第一客户端的发送消息流程，可以包括如下步骤：
154.①
构造协议头标识，如：0x47 0x48。
155.②
构造协议版本号，如：0x01。
156.③
标识数据加密方式，如：0x11表示i帧aes加密方式，0x00表示无加密，0x22数据全加密，加密方式为des。
157.④
标识数据类型：加密密钥、视频数据、音频数据等。
158.⑤
根据步骤4标识的加密方式，加密要发送的数据。
159.⑥
标识数据长度。
160.⑦
填充加密后的数据。
161.⑧
用crc校验将整个消息(除协议头：0x47 0x48)生成校验码。
162.⑨
通过datachannel数据通道将消息发送给第二客户端，完成此次消息发送过程。
163.对于第二客户端的接收消息流程，可以包括如下步骤：
164.①
通过datachannel数据通道得到第一客户端发送的消息。
165.②
检查协议头0x47 0x48，如果协议头不对，则向后续数据依次检查匹配协议头，直到第一次得到协议头，并将此前无效数据丢弃。
166.③
通过3bytes偏移，得到4bytes数据长度。
167.④
通过得到的数据长度进行偏移，得到crc校验码。
168.⑤
通过校验码校验此次消息的有效性，校验不通过则丢弃掉此次消息。
169.⑥
通过偏移得到协议版本号，检查是否支持此协议的解析，不支持则丢弃消息。
170.⑦
通过偏移得到数据加密方式，选择相应的解密方式。
171.⑧
通过偏移得到数据类型，选择相应的解析方式。
172.⑨
通过偏移得到第一客户端发过来的完整数据，解密数据。
173.⑩
完成此次消息接收过程。
174.上述实施例的私有协议，充分考虑了原有webrtc协议的特性而设计，由于webrtc使用tcp/udp协议传输，易于被抓包、嗅探和恶意攻击，在现有webrtc标准协议基础上增加wktp私有协议，能够增加传输安全性，增加破解难度；同时，经过实测显示，wktp私有协议在网络ktv系统中具有良好的扩展性，在其他非webrtc客户端上传输时也具有良好效果。
175.下面阐述本技术的文件传输装置的实施例。
176.参考图9所示，图9是一个实施例的文件传输装置的结构示意图，包括：
177.通道连接单元10，用于基于rtc协议建立第一客户端与第二客户端之间的data channel数据通道；
178.协议发送单元20，用于从所述第一客户端获取歌曲文件，利用私有协议对所述歌曲文件封装后得到传输文件协议包，通过所述data channel数据通道发送至第二客户端；其中，所述私有协议是基于rtc协议且承载于所述data channel数据通道上；
179.协议解析单元30，用于获取所述第二客户端接收的rtc数据包，从所述rtc数据包中提取出传输文件协议包，并依据所述私有协议解析所述传输文件协议包得到对应的歌曲文件。
180.本实施例的文件传输装置可执行本公开的实施例所提供的一种文件传输方法，其
实现原理相类似，本公开各实施例中的文件传输装置中的各模块所执行的动作是与本公开各实施例中的文件传输方法中的步骤相对应的，对于文件传输装置的各模块的详细功能描述具体可以参见前文中所示的对应的文件传输方法中的描述，此处不再赘述。
181.下面阐述本技术网络ktv系统的实施例。
182.本技术提供的一种网络ktv系统，包括：多个通过网络连接的ktv盒子；其中，所述ktv盒子中的至少一者对应包上述任意实施例的第一客户端，以及至少一者对应包括上述任意实施例的第二客户端。
183.如图1所示，图中可以构成一个网络ktv系统，在使用过程中，各个客户端都可以使用webrtc协议与其他客户端进行通信，任意一个客户端，当需要与其他客户端进行文件传输时，基于本技术提供的文件传输方案，结合提供的wktp协议，可以实现不同终端之间的跨平台通信，具有更高的传输效率，具有更高的文件传输的安全性。
184.下面阐述本技术的计算机设备的实施例，该计算机设备，其包括：
185.一个或多个处理器；
186.存储器；
187.一个或多个应用程序，其中所述一个或多个应用程序被存储在所述存储器中并被配置为由所述一个或多个处理器执行，所述一个或多个程序配置用于：执行根据上述任意实施例的文件传输方法。
188.下面阐述本技术的计算机可读存储介质的实施例，，所述存储介质存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行上述任意实施例的文件传输方法。
189.上述实施例的计算机设备及计算机可读存储介质，基于本技术提供的文件传输方案，结合提供的wktp协议，可以实现不同终端之间的跨平台通信，具有更高的传输效率，具有更高的文件传输的安全性。
190.以上所述仅是本技术的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本技术原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本技术的保护范围。