CN103684707B - 服务端、用户端消息传输处理方法、消息传输方法及*** - Google Patents
服务端、用户端消息传输处理方法、消息传输方法及*** Download PDFInfo
- Publication number
- CN103684707B CN103684707B CN201310713569.8A CN201310713569A CN103684707B CN 103684707 B CN103684707 B CN 103684707B CN 201310713569 A CN201310713569 A CN 201310713569A CN 103684707 B CN103684707 B CN 103684707B
- Authority
- CN
- China
- Prior art keywords
- message
- service end
- user side
- time
- sends
- 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
- 230000005540 biological transmission Effects 0.000 title claims abstract description 200
- 238000000034 method Methods 0.000 title claims abstract description 46
- 238000003672 processing method Methods 0.000 title abstract 2
- 238000012545 processing Methods 0.000 claims description 22
- 235000013399 edible fruits Nutrition 0.000 claims 1
- 230000006854 communication Effects 0.000 abstract description 22
- 238000004891 communication Methods 0.000 abstract description 18
- 238000012790 confirmation Methods 0.000 abstract description 10
- 230000003247 decreasing effect Effects 0.000 abstract 1
- 238000005516 engineering process Methods 0.000 description 2
- 238000004321 preservation Methods 0.000 description 2
- 238000004590 computer program Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
本发明提供一种服务端、用户端消息传输处理方法、消息传输方法及***。通过在服务端发送的消息中添加服务端本次消息发送时间和服务端上一次消息发送时间后发送给用户端，使用户端可以根据所述消息中的服务端上一次消息发送时间与用户端上一次消息接收时间是否对比相同，从而确定服务端发送的消息有无丢失，如果丢失可通过对所述服务端发送消息重传指令，请求重新发送用户端上一次消息接收时间到服务端本次消息发送时间之间丢失的消息。用户端无需再每次接受消息后都对服务端发送去确认消息，减少发送确认消息对服务端造成的性能影响，并且不会增加用户端的流量。尤其在多人会话、群组会话的通信方式中能够大大减少服务端的负担。
Description
技术领域
本发明涉及网络消息传输的技术领域，特别是涉及一种服务端的消息传输处理方法及其***，一种用户端的消息传输处理方法及其***。
背景技术
随着网络技术的发展，越来越多的应用支持多人会话，但网络有着明显的不稳定性，从而导致多人会话的消息到达率会比较低，也就是多人会话可能会丢失部分消息。
一般要解决消息丢失的问题，都通过接收端回复确认消息来保证，ACK(Acknowledgement，确认消息)是在数据通信中，接收点发给发送端的一种传输类消息，表示发送端发来的数据已确认接受无误。
现有的多人会话通常以网络群组的方式进行。在即时通信***中，将有相同爱好或者特征的人群集合到一起可以聊天和交流的平台就是群组。
如图1所示：用户1发送一条群组消息到群组逻辑进程(箭头1、2)，群组逻辑进程广播给群组中的其它用户(箭头3、4、5、6)，其它用户收到消息后回复ACK消息到群组逻辑，到此整个消息发送流程才完结。这种消息传输方法有二个主要缺点：
1.所有接收到消息的用户端都要回复ACK，增加群组逻辑进程的负担，当群组用户成百上千的时候会严重影响群组逻辑服务端的进程性能；
2.用户端回复的ACK消息增加用户端的流量。
发明内容
针对现有消息传输方法中接收用户回复确认消息影响服务端性能，增加用户端流量的问题。本发明提出一种服务端的消息传输处理方法及其***，能够准确检测传输的消息是否丢失，且无需接收消息的用户端发送确认消息，减少发送确认消息对服务端造成的性能影响，不会增加用户端的流量。
一种服务端的消息传输处理方法，包括以下步骤：
在服务端发送的消息中添加服务端本次消息发送时间和服务端上一次消息发送时间，将所述消息发送给用户端；
如果接收到所述用户端发送的消息重传指令，其中，所述消息重传指令包括用户端上一次消息接收时间，则向所述用户端重新发送所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间对所述用户端发送的消息。
一种服务端的消息传输处理***，包括：
消息发送模块，用于在服务端发送的消息中添加服务端本次消息发送时间和服务端上一次消息发送时间，将所述消息发送给用户端；
消息重传模块，用于如果接收到所述用户端发送的消息重传指令，其中，所述消息重传指令包括用户端上一次消息接收时间，则向所述用户端重新发送所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间对所述用户端发送的消息。
本发明的服务端的消息传输处理方法及其***中，通过在服务端发送的消息中添加服务端本次消息发送时间和服务端上一次消息发送时间后发送给用户端，使用户端可以根据所述消息中的服务端上一次消息发送时间与用户端上一次消息接收时间是否对比相同，从而确定服务端发送的消息有无丢失，如果丢失可通过对所述服务端发送消息重传指令，请求重新发送用户端上一次消息接收时间到服务端本次消息发送时间之间丢失的消息。用户端无需再每次接受消息后都对服务端发送去确认消息，减少发送确认消息对服务端造成的性能影响，并且不会增加用户端的流量。尤其在多人会话、群组会话的通信方式中能够大大减少服务端的负担。
针对上述问题，本发明还提出一种用户端的消息传输处理方法及其***，能够准确检测传输的消息是否丢失，且无需接收消息的用户端发送确认消息，减少发送确认消息对服务端造成的性能影响，不会增加用户端的流量。
一种用户端的消息传输处理方法，包括以下步骤：
接收服务端发送的消息，其中，所述服务端发送的消息中包括服务端本次消息发送时间和服务端上一次消息发送时间；
根据所述服务端本次消息发送时间更新用户端消息接收时间，并将所述服务端上一次消息发送时间与用户端上一次消息接收时间比较，如果二者不相同，则向服务端发送消息重传指令，请求重新发送所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间对所述用户端发送的消息。
一种用户端的消息传输处理***，包括：
消息接收模块，用于接收服务端发送的消息，其中，所述服务端发送的消息中包括服务端本次消息发送时间和服务端上一次消息发送时间；
重传请求模块，用于根据所述服务端本次消息发送时间更新用户端消息接收时间，并将所述服务端上一次消息发送时间与用户端上一次消息接收时间比较，如果二者不相同，则向服务端发送消息重传指令，请求重新发送所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间对所述用户端发送的消息。
本发明的用户端的消息传输处理方法及其***中，接收服务端发送的消息中包括服务端本次消息发送时间和服务端上一次消息发送时间。因此，用户端可以根据所述消息中的服务端上一次消息发送时间与用户端上一次消息接收时间是否对比相同，从而确定服务端发送的消息有无丢失，如果丢失可通过对所述服务端发送消息重传指令，请求重新发送用户端上一次消息接收时间到服务端本次消息发送时间之间丢失的消息。用户端无需再每次接受消息后都对服务端发送去确认消息，减少发送确认消息对服务端造成的性能影响，并且不会增加用户端的流量。尤其在多人会话、群组会话的通信方式中能够大大减少服务端的负担。
针对上述问题，本发明还提出一种消息传输方法及其***，能够准确检测传输的消息是否丢失，且无需接收消息的用户端发送确认消息，减少发送确认消息对服务端造成的性能影响，不会增加用户端的流量。
一种消息传输方法，包括以下步骤：
服务端在发送给用户端的消息中添加服务端本次消息发送时间和服务端上一次消息发送时间，将所述消息发送给用户端；
用户端接收服务端发送的消息，并根据所述服务端本次消息发送时间更新用户端消息接收时间，将所述服务端上一次消息发送时间与所述用户端上一次消息接收时间比较，如果二者不相同，则向所述服务端发送消息重传指令，其中，所述消息重传指令包括用户端上一次消息接收时间；
服务端接收到所述消息重传指令时，重新发送所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间对所述用户端发送的消息。
一种消息传输***，包括服务端和用户端：
所述服务端用于在发送给用户端的消息中添加服务端本次消息发送时间和服务端上一次消息发送时间，将所述消息发送给用户端；并在接收到用户端发送的消息重传指令时，重新发送所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间对所述用户端发送的消息；
所述用户端用于接收服务端发送的消息，并根据所述服务端本次消息发送时间更新用户端消息接收时间，将所述服务端上一次消息发送时间与所述用户端上一次消息接收时间比较，如果二者不相同，则向所述服务端发送消息重传指令，其中，所述消息重传指令包括用户端上一次消息接收时间。
本发明的消息传输方法及其***中，服务端发送的消息中包括服务端本次消息发送时间和服务端上一次消息发送时间。因此，用户端可以根据所述消息中的服务端上一次消息发送时间与用户端上一次消息接收时间是否对比相同，从而确定服务端发送的消息有无丢失，如果丢失可通过对所述服务端发送消息重传指令，请求重新发送用户端上一次消息接收时间到服务端本次消息发送时间之间丢失的消息。服务端根据所述消息重传指令重传相应的消息，消除消息丢失的影响。并且用户端无需再每次接受消息后都对服务端发送去确认消息，减少发送确认消息对服务端造成的性能影响，并且不会增加用户端的流量。尤其在多人会话、群组会话的通信方式中能够大大减少服务端的负担。
附图说明
图1是一种现有的数据传输方法的示意图；
图2是本发明服务端的消息传输处理方法的流程示意图；
图3是本发明用户端的消息传输处理方法的流程示意图；
图4是本发明消息传输方法的流程示意图；
图5是本发明服务端的消息传输处理***的结构示意图；
图6是本发明用户端的消息传输处理***的结构示意图；
图7是本发明消息传输***的结构示意图。
具体实施方式
请参阅图2，图2是本发明服务端的消息传输处理方法的流程示意图。
所述服务端的消息传输处理方法，包括以下步骤：
S202，在服务端发送的消息中添加服务端本次消息发送时间和服务端上一次消息发送时间，将所述消息发送给用户端；
S204，如果接收到所述用户端发送的消息重传指令，其中，所述消息重传指令包括用户端上一次消息接收时间，则向所述用户端重新发送所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间对所述用户端发送的消息。
本发明的服务端的消息传输处理方法中，通过在服务端发送的消息中添加服务端本次消息发送时间和服务端上一次消息发送时间后发送给用户端，使用户端可以根据所述消息中的服务端上一次消息发送时间与用户端上一次消息接收时间是否对比相同，从而确定服务端发送的消息有无丢失，如果丢失可通过对所述服务端发送消息重传指令，请求重新发送用户端上一次消息接收时间到服务端本次消息发送时间之间丢失的消息。用户端无需再每次接受消息后都对服务端发送去确认消息，减少发送确认消息对服务端造成的性能影响，并且不会增加用户端的流量。尤其在多人会话、群组会话的通信方式中能够大大减少服务端的负担。
其中，为获得所述服务端本次消息发送时间和服务端上一次消息发送时间，可以在所述服务端发送每个消息时对所述消息的发送时间进行保存。
在一个优选实施方式中，可对各个接收数据的用户端都创建一个发送消息队列，所述发送消息队列中保存预定时间内服务端对所述用户端发送的消息，以及各个消息的发送时间。则，根据所述发送消息队列，可以查找到对相应的用户端的上一次消息发送时间。
对于群组通信的情况下，步骤S202可以具体为：
接收用户端发送的群组消息至服务端，在所述群组消息中添加服务端本次消息发送时间和服务端上一次消息发送时间，并将所述群组消息发送给所述群组的其他用户端。
在用户与用户之间的通信过程中，发送用户端将消息发送到服务端，服务端再将所述消息转发到相应的接收用户端。因此，在这种情形下，所述服务端发送消息的时间可以等于所述发送用户端将消息发送至服务端的时间，记为sendtime，可以64位毫秒数表示。而所述服务端上一次发送消息的时间也等于所述发送用户端上一次将消息发送至服务端的时间，记为lasttime，也可以64位毫秒数表示。
因为服务端对用户端第一次发送消息时，没有所谓的上一次发送消息的时间，因此服务端对用户端第一次发送的消息设置lasttime＝0。
步骤S204中，如果接收到所述用户端发送的消息重传指令，则根据所述消息重传指令重传相应的消息。
其中，所述消息重传指令至少包括用户端上一次消息接收时间，所述服务端可根据所述消息重传指令，获取所述用户端上一次消息接收时间；然后可以根据自身保存的发送消息记录自行获取服务端本次消息发送时间，在所述服务端保存的历史发送消息记录(如上述的发送消息队列)中查找从所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间所述服务端对所述用户端发送的消息，将对应的所述消息重新发送到所述用户端。
在一个优选实施例中，考虑到重传消息发送到服务端可能有延时。所述消息重传指令进一步包括所述服务端本次消息发送时间。则所述服务端可以直接根据所述消息重传指令中包含的两个时间点，直接查找这段时间内对相应用户端发送的消息，然后执行重传操作。
请参阅图3，图3是本发明用户端的消息传输处理方法的流程示意图。
所述用户端的消息传输处理方法，包括以下步骤：
S302，接收服务端发送的消息，其中，所述服务端发送的消息中包括服务端本次消息发送时间和服务端上一次消息发送时间；
S304，根据所述服务端本次消息发送时间更新用户端消息接收时间，并将所述服务端上一次消息发送时间与用户端上一次消息接收时间比较，如果二者不相同，则向服务端发送消息重传指令，请求重新发送所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间对所述用户端发送的消息。
本发明的用户端的消息传输处理方法中，接收服务端发送的消息中包括服务端本次消息发送时间和服务端上一次消息发送时间。因此，用户端可以根据所述消息中的服务端上一次消息发送时间与用户端上一次消息接收时间是否对比相同，从而确定服务端发送的消息有无丢失，如果丢失可通过对所述服务端发送消息重传指令，请求重新发送用户端上一次消息接收时间到服务端本次消息发送时间之间丢失的消息。用户端无需再每次接受消息后都对服务端发送去确认消息，减少发送确认消息对服务端造成的性能影响，并且不会增加用户端的流量。尤其在多人会话、群组会话的通信方式中能够大大减少服务端的负担。
其中，所述服务端发送的消息中包括的服务端本次消息发送时间和服务端上一次消息发送时间，由服务端设定。服务端可以对各个接收数据的用户端都创建一个发送消息队列，所述发送消息队列中保存预定时间内服务端对所述用户端发送的消息，以及各个消息的发送时间。则，根据所述发送消息队列，可以查找到对相应的用户端的上一次消息发送时间
在用户与用户之间的通信情形下，发送用户端将消息发送到服务端，服务端再将所述消息转发到相应的接收用户端。因此，在这种情形下，所述服务端发送消息的时间可以等于所述发送用户端将消息发送至服务端的时间，记为sendtime，可以64位毫秒数表示。而所述服务端上一次发送消息的时间也等于所述发送用户端上一次将消息发送至服务端的时间，记为lasttime，也可以64位毫秒数表示。
步骤S304中，根据所述服务端本次消息发送时间更新用户端消息接收时间，并将所述服务端上一次消息发送时间与用户端上一次消息接收时间比较。
所述用户端每次接受到服务端发送的消息时，记录所述消息的接收时间，可将各个消息的接收时间记录成接收时间队列，所述接收时间队列至少包含有上一次消息接收时间。从而在每一次接收到消息的时候查找到上一次消息接收的时间。
然后，将从所述服务端发送的本次消息中获取到的所述服务端上一次消息发送时间，与查找到的用户端上一次消息接收时间比较。
如果两个时间相同，则说明证明在用户端两次接收消息之间没有其他消息丢失，因此可直接保存所述消息；如果两个时间不相同，则说明在用户端两次接收消息之间所述服务端还发送了其他的消息，而用户端没有收到，即这两个时间之间的消息发生丢失，因此向服务端发送消息重传指令，请求重新发送所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间对所述用户端发送的消息。
其中，所述消息重传指令至少包括用户端上一次消息接收时间，所述服务端可根据所述消息重传指令，获取所述用户端上一次消息接收时间；然后可以根据自身保存的发送消息记录自行获取服务端本次消息发送时间，在所述服务端保存的历史发送消息记录(如上述的发送消息队列)中查找从所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间所述服务端对所述用户端发送的消息，将对应的所述消息重新发送到所述用户端。
在一个优选实施例中，考虑到重传消息发送到服务端可能有延时。所述消息重传指令进一步包括所述服务端本次消息发送时间。则所述服务端可以直接根据所述消息重传指令中包含的两个时间点，直接查找这段时间内对相应用户端发送的消息，然后执行重传操作。
针对服务端对用户端第一次发送消息的情况，进一步执行以下处理：
判断所述服务端上一次消息发送时间是否为0，如果是，则直接保存所述消息，并根据所述服务端本次消息发送时间更新用户端消息接收时间。
请参阅图4，图4是本发明消息传输方法的流程示意图。
所述消息传输方法，包括以下步骤：
S402，服务端在发送给用户端的消息中添加服务端本次消息发送时间和服务端上一次消息发送时间，将所述消息发送给用户端；
S404，用户端接收服务端发送的消息，并根据所述服务端本次消息发送时间更新用户端消息接收时间，将所述服务端上一次消息发送时间与所述用户端上一次消息接收时间比较，如果二者不相同，则向所述服务端发送消息重传指令，其中，所述消息重传指令包括用户端上一次消息接收时间；
S406，服务端接收到所述消息重传指令时，重新发送所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间对所述用户端发送的消息。
本发明的消息传输方法中，服务端发送的消息中包括服务端本次消息发送时间和服务端上一次消息发送时间。因此，用户端可以根据所述消息中的服务端上一次消息发送时间与用户端上一次消息接收时间是否对比相同，从而确定服务端发送的消息有无丢失，如果丢失可通过对所述服务端发送消息重传指令，请求重新发送用户端上一次消息接收时间到服务端本次消息发送时间之间丢失的消息。服务端根据所述消息重传指令重传相应的消息，消除消息丢失的影响。并且用户端无需再每次接受消息后都对服务端发送去确认消息，减少发送确认消息对服务端造成的性能影响，并且不会增加用户端的流量。尤其在多人会话、群组会话的通信方式中能够大大减少服务端的负担。
其中，所述服务端为获得所述服务端本次消息发送时间和服务端上一次消息发送时间，可以在所述服务端发送每个消息时对所述消息的发送时间进行保存。
在一个优选实施方式中，所述服务端可对各个接收数据的用户端都创建一个发送消息队列，所述发送消息队列中保存预定时间内服务端对所述用户端发送的消息，以及各个消息的发送时间。则，根据所述发送消息队列，可以查找到对相应的用户端的上一次消息发送时间。
对于群组通信的情况下，步骤S402可以具体为：
接收用户端发送的群组消息至服务端，在所述群组消息中添加服务端本次消息发送时间和服务端上一次消息发送时间，并将所述群组消息发送给所述群组的其他用户端。
在用户与用户之间的通信过程中，发送用户端将消息发送到服务端，服务端再将所述消息转发到相应的接收用户端。因此，在这种情形下，所述服务端发送消息的时间可以等于所述发送用户端将消息发送至服务端的时间，记为sendtime，可以64位毫秒数表示。而所述服务端上一次发送消息的时间也等于所述发送用户端上一次将消息发送至服务端的时间，记为lasttime，也可以64位毫秒数表示。
因为服务端对用户端第一次发送消息时，没有所谓的上一次发送消息的时间，因此服务端对用户端第一次发送的消息设置lasttime＝0。
步骤S404中，用户端根据所述服务端本次消息发送时间更新用户端消息接收时间，并将从所述服务端发送的本次消息中获取到的所述服务端上一次消息发送时间，与查找到的用户端上一次消息接收时间比较。
如果两个时间相同，则说明证明在用户端两次接收消息之间没有其他消息丢失，因此可直接保存所述消息；如果两个时间不相同，则说明在用户端两次接收消息之间所述服务端还发送了其他的消息，而用户端没有收到，即这两个时间之间的消息发生丢失，因此向服务端发送消息重传指令，请求重新发送所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间对所述用户端发送的消息。
其中，所述消息重传指令至少包括用户端上一次消息接收时间，所述服务端可根据所述消息重传指令，获取所述用户端上一次消息接收时间；然后可以根据自身保存的发送消息记录自行获取服务端本次消息发送时间，在所述服务端保存的历史发送消息记录(如上述的发送消息队列)中查找从所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间所述服务端对所述用户端发送的消息，将对应的所述消息重新发送到所述用户端。
在一个优选实施例中，考虑到重传消息发送到服务端可能有延时。所述消息重传指令进一步包括所述服务端本次消息发送时间。则所述服务端可以直接根据所述消息重传指令中包含的两个时间点，直接查找这段时间内对相应用户端发送的消息，然后执行重传操作。
针对服务端对用户端第一次发送消息的情况，所述用户端可进一步执行以下处理：
判断所述服务端上一次消息发送时间是否为0，如果是，则直接保存所述消息，并根据所述服务端本次消息发送时间更新用户端消息接收时间。
步骤S406中，服务端接收到所述用户端发送的消息重传指令，根据所述消息重传指令重传相应的消息。
请参阅图5，图5是本发明服务端的消息传输处理***的结构示意图。
所述服务端的消息传输处理***，包括：
消息发送模块51，用于在服务端发送的消息中添加服务端本次消息发送时间和服务端上一次消息发送时间，将所述消息发送给用户端；
消息重传模块52，用于如果接收到所述用户端发送的消息重传指令，其中，所述消息重传指令包括用户端上一次消息接收时间，则向所述用户端重新发送所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间对所述用户端发送的消息。
本发明的服务端的消息传输处理***中，通过在服务端发送的消息中添加服务端本次消息发送时间和服务端上一次消息发送时间后发送给用户端，使用户端可以根据所述消息中的服务端上一次消息发送时间与用户端上一次消息接收时间是否对比相同，从而确定服务端发送的消息有无丢失，如果丢失可通过对所述服务端发送消息重传指令，请求重新发送用户端上一次消息接收时间到服务端本次消息发送时间之间丢失的消息。用户端无需再每次接受消息后都对服务端发送去确认消息，减少发送确认消息对服务端造成的性能影响，并且不会增加用户端的流量。尤其在多人会话、群组会话的通信方式中能够大大减少服务端的负担。
其中，为获得所述服务端本次消息发送时间和服务端上一次消息发送时间，所述消息发送模块51可以在所述服务端发送每个消息时对所述消息的发送时间进行保存。
在一个优选实施方式中，所述消息发送模块51可对各个接收数据的用户端都创建一个发送消息队列，所述发送消息队列中保存预定时间内服务端对所述用户端发送的消息，以及各个消息的发送时间。则，根据所述发送消息队列，可以查找到对相应的用户端的上一次消息发送时间。
对于群组通信的情况下，所述消息发送模块51接收用户端发送的群组消息至服务端，在所述群组消息中添加服务端本次消息发送时间和服务端上一次消息发送时间，并将所述群组消息发送给所述群组的其他用户端。
在用户与用户之间的通信过程中，发送用户端将消息发送到服务端，服务端再将所述消息转发到相应的接收用户端。因此，在这种情形下，所述服务端发送消息的时间可以等于所述发送用户端将消息发送至服务端的时间，记为sendtime，可以64位毫秒数表示。而所述服务端上一次发送消息的时间也等于所述发送用户端上一次将消息发送至服务端的时间，记为lasttime，也可以64位毫秒数表示。
因为服务端对用户端第一次发送消息时，没有所谓的上一次发送消息的时间，因此服务端对用户端第一次发送的消息设置lasttime＝0。
所述消息重传模块52如果接收到所述用户端发送的消息重传指令，则根据所述消息重传指令重传相应的消息。
其中，所述消息重传指令至少包括用户端上一次消息接收时间，所述服务端的所述消息重传模块52可根据所述消息重传指令，获取所述用户端上一次消息接收时间；然后可以根据自身保存的发送消息记录自行获取服务端本次消息发送时间，在所述服务端保存的历史发送消息记录(如上述的发送消息队列)中查找从所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间所述服务端对所述用户端发送的消息，将对应的所述消息重新发送到所述用户端。
在一个优选实施例中，考虑到重传消息发送到服务端可能有延时。所述消息重传指令进一步包括所述服务端本次消息发送时间。则所述服务端的所述消息重传模块52可以直接根据所述消息重传指令中包含的两个时间点，直接查找这段时间内对相应用户端发送的消息，然后执行重传操作。
请参阅图6，图6是本发明用户端的消息传输处理***的结构示意图。
所述用户端的消息传输处理方法，包括以下步骤：
消息接收模块61，用于接收服务端发送的消息，其中，所述服务端发送的消息中包括服务端本次消息发送时间和服务端上一次消息发送时间；
重传请求模块62，用于根据所述服务端本次消息发送时间更新用户端消息接收时间，并将所述服务端上一次消息发送时间与用户端上一次消息接收时间比较，如果二者不相同，则向服务端发送消息重传指令，请求重新发送所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间对所述用户端发送的消息。
本发明的用户端的消息传输处理***中，接收服务端发送的消息中包括服务端本次消息发送时间和服务端上一次消息发送时间。因此，用户端可以根据所述消息中的服务端上一次消息发送时间与用户端上一次消息接收时间是否对比相同，从而确定服务端发送的消息有无丢失，如果丢失可通过对所述服务端发送消息重传指令，请求重新发送用户端上一次消息接收时间到服务端本次消息发送时间之间丢失的消息。用户端无需再每次接受消息后都对服务端发送去确认消息，减少发送确认消息对服务端造成的性能影响，并且不会增加用户端的流量。尤其在多人会话、群组会话的通信方式中能够大大减少服务端的负担。
其中，所述服务端发送的消息中包括的服务端本次消息发送时间和服务端上一次消息发送时间，由服务端设定。服务端可以对各个接收数据的用户端都创建一个发送消息队列，所述发送消息队列中保存预定时间内服务端对所述用户端发送的消息，以及各个消息的发送时间。则，根据所述发送消息队列，可以查找到对相应的用户端的上一次消息发送时间
在用户与用户之间的通信情形下，发送用户端将消息发送到服务端，服务端再将所述消息转发到相应的接收用户端。因此，在这种情形下，所述服务端发送消息的时间可以等于所述发送用户端将消息发送至服务端的时间，记为sendtime，可以64位毫秒数表示。而所述服务端上一次发送消息的时间也等于所述发送用户端上一次将消息发送至服务端的时间，记为lasttime，也可以64位毫秒数表示。
所述重传请求模块62首先根据所述服务端本次消息发送时间更新用户端消息接收时间，并将所述服务端上一次消息发送时间与用户端上一次消息接收时间比较。
所述用户端每次接受到服务端发送的消息时，记录所述消息的接收时间，可将各个消息的接收时间记录成接收时间队列，所述接收时间队列至少包含有上一次消息接收时间。从而在每一次接收到消息的时候查找到上一次消息接收的时间。
然后，将从所述服务端发送的本次消息中获取到的所述服务端上一次消息发送时间，与查找到的用户端上一次消息接收时间比较。
如果两个时间相同，则说明证明在用户端两次接收消息之间没有其他消息丢失，因此可直接保存所述消息；如果两个时间不相同，则说明在用户端两次接收消息之间所述服务端还发送了其他的消息，而用户端没有收到，即这两个时间之间的消息发生丢失，因此所述重传请求模块62向服务端发送消息重传指令，请求重新发送所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间对所述用户端发送的消息。
其中，所述消息重传指令至少包括用户端上一次消息接收时间，所述服务端可根据所述消息重传指令，获取所述用户端上一次消息接收时间；然后可以根据自身保存的发送消息记录自行获取服务端本次消息发送时间，在所述服务端保存的历史发送消息记录(如上述的发送消息队列)中查找从所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间所述服务端对所述用户端发送的消息，将对应的所述消息重新发送到所述用户端。
在一个优选实施例中，考虑到重传消息发送到服务端可能有延时。所述消息重传指令进一步包括所述服务端本次消息发送时间。则所述服务端可以直接根据所述消息重传指令中包含的两个时间点，直接查找这段时间内对相应用户端发送的消息，然后执行重传操作。
针对服务端对用户端第一次发送消息的情况，进一步执行以下处理：
判断所述服务端上一次消息发送时间是否为0，如果是，则直接保存所述消息，并根据所述服务端本次消息发送时间更新用户端消息接收时间。
请参阅图7，图7是本发明消息传输方法的流程示意图。
所述消息传输***，包括：服务端71和用户端72：
所述服务端71用于在发送给用户端的消息中添加服务端本次消息发送时间和服务端上一次消息发送时间，将所述消息发送给用户端；并在接收到用户端发送的消息重传指令时，重新发送所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间对所述用户端发送的消息；
所述用户端72用于接收服务端发送的消息，并根据所述服务端本次消息发送时间更新用户端消息接收时间，将所述服务端上一次消息发送时间与所述用户端上一次消息接收时间比较，如果二者不相同，则向所述服务端发送消息重传指令，其中，所述消息重传指令包括用户端上一次消息接收时间。
本发明的消息传输***中，服务端发送的消息中包括服务端本次消息发送时间和服务端上一次消息发送时间。因此，用户端可以根据所述消息中的服务端上一次消息发送时间与用户端上一次消息接收时间是否对比相同，从而确定服务端发送的消息有无丢失，如果丢失可通过对所述服务端发送消息重传指令，请求重新发送用户端上一次消息接收时间到服务端本次消息发送时间之间丢失的消息。服务端根据所述消息重传指令重传相应的消息，消除消息丢失的影响。并且用户端无需再每次接受消息后都对服务端发送去确认消息，减少发送确认消息对服务端造成的性能影响，并且不会增加用户端的流量。尤其在多人会话、群组会话的通信方式中能够大大减少服务端的负担。
其中，服务端71为获得所述服务端本次消息发送时间和服务端上一次消息发送时间，可以在所述服务端71发送每个消息时对所述消息的发送时间进行保存。
在一个优选实施方式中，所述服务端71可对各个接收数据的用户端72都创建一个发送消息队列，所述发送消息队列中保存预定时间内服务端71对所述用户端72发送的消息，以及各个消息的发送时间。则，根据所述发送消息队列，可以查找到对相应的用户端72的上一次消息发送时间。
对于群组通信的情况下，所述服务端71接收用户端72发送的群组消息，在所述群组消息中添加服务端本次消息发送时间和服务端上一次消息发送时间，并将所述群组消息发送给所述群组的其他用户端72。
在用户与用户之间的通信过程中，发送用户端72将消息发送到服务端71，所述服务端71再将所述消息转发到相应的接收用户端72。因此，在这种情形下，所述服务端71发送消息的时间可以等于所述发送用户端72将消息发送至服务端的时间，记为sendtime，可以64位毫秒数表示。而所述服务端上一次发送消息的时间也等于所述发送用户端上一次将消息发送至服务端的时间，记为lasttime，也可以64位毫秒数表示。
因为所述服务端71对所述用户端72第一次发送消息时，没有所谓的上一次发送消息的时间，因此服务端对用户端第一次发送的消息设置lasttime＝0。
所述用户端72根据所述服务端本次消息发送时间更新用户端消息接收时间，并将从所述服务端发送的本次消息中获取到的所述服务端上一次消息发送时间，与查找到的用户端上一次消息接收时间比较。
如果两个时间相同，则说明证明在用户端两次接收消息之间没有其他消息丢失，因此可直接保存所述消息；如果两个时间不相同，则说明在用户端两次接收消息之间所述服务端还发送了其他的消息，而用户端没有收到，即这两个时间之间的消息发生丢失，因此向服务端71发送消息重传指令，请求重新发送所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间对所述用户端发送的消息。
其中，所述消息重传指令至少包括用户端上一次消息接收时间，所述服务端71可根据所述消息重传指令，获取所述用户端上一次消息接收时间；然后可以根据自身保存的发送消息记录自行获取服务端本次消息发送时间，在所述服务端保存的历史发送消息记录(如上述的发送消息队列)中查找从所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间所述服务端对所述用户端发送的消息，将对应的所述消息重新发送到所述用户端。
在一个优选实施例中，考虑到重传消息发送到服务端可能有延时。所述消息重传指令进一步包括所述服务端本次消息发送时间。则所述服务端71可以直接根据所述消息重传指令中包含的两个时间点，直接查找这段时间内对相应用户端发送的消息，然后执行重传操作。
针对服务端对用户端第一次发送消息的情况，所述用户端72可进一步执行以下处理：
判断所述服务端上一次消息发送时间是否为0，如果是，则直接保存所述消息，并根据所述服务端本次消息发送时间更新用户端消息接收时间。
所述服务端71接收到所述用户端发送的消息重传指令后，根据所述消息重传指令重传相应的消息。
本领域普通技术人员可以理解实现上述实施方式中的全部或部分流程以及对应的***、所述音乐播放器，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各实施方式的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。
以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。
Claims (12)
1.一种服务端的消息传输处理方法，其特征在于，包括以下步骤：
在服务端发送的消息中添加服务端本次消息发送时间和服务端上一次消息发送时间，将所述消息发送给用户端；
如果接收到所述用户端发送的消息重传指令，其中，所述消息重传指令包括用户端上一次消息接收时间，则向所述用户端重新发送所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间对所述用户端发送的消息。
2.如权利要求1所述的服务端的消息传输处理方法，其特征在于，在服务端发送的消息中添加服务端本次消息发送时间和服务端上一次消息发送时间，将所述消息发送给用户端的步骤包括：
接收用户端发送的群组消息至服务端，在所述群组消息中添加服务端本次消息发送时间和服务端上一次消息发送时间，并将所述群组消息发送给所述群组的其他用户端。
3.如权利要求1或者2所述的服务端的消息传输处理方法，其特征在于，向所述用户端重新发送所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间对所述用户端发送的消息的步骤包括：
根据所述消息重传指令，获取所述用户端上一次消息接收时间；
在所述服务端保存的历史发送消息记录中查找从所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间所述服务端对所述用户端发送的消息，将对应的所述消息重新发送到所述用户端。
4.一种服务端的消息传输处理***，其特征在于，包括：
消息发送模块，用于在服务端发送的消息中添加服务端本次消息发送时间和服务端上一次消息发送时间，将所述消息发送给用户端；
消息重传模块，用于如果接收到所述用户端发送的消息重传指令，其中，所述消息重传指令包括用户端上一次消息接收时间，则向所述用户端重新发送所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间对所述用户端发送的消息。
5.如权利要求4所述的服务端的消息传输处理***，其特征在于，所述消息发送模块还用于接收用户端发送的群组消息至服务端，在所述群组消息中添加服务端本次消息发送时间和服务端上一次消息发送时间，并将所述群组消息发送给所述群组的其他用户端。
6.如权利要求4或者5所述的服务端的消息传输处理***，其特征在于，所述消息重传模块根据所述消息重传指令，获取所述用户端上一次消息接收时间；在所述服务端保存的历史发送消息记录中查找从所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间所述服务端对所述用户端发送的消息，将对应的所述消息重新发送到所述用户端。
7.一种用户端的消息传输处理方法，其特征在于，包括以下步骤：
接收服务端发送的消息，其中，所述服务端发送的消息中包括服务端本次消息发送时间和服务端上一次消息发送时间；
根据所述服务端本次消息发送时间更新用户端消息接收时间，并将所述服务端上一次消息发送时间与用户端上一次消息接收时间比较，如果二者不相同，则向服务端发送消息重传指令，请求重新发送所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间对所述用户端发送的消息。
8.如权利要求7所述的用户端的消息传输处理方法，其特征在于，进一步包括：
判断所述服务端上一次消息发送时间是否为0，如果是，则直接保存所述消息，并根据所述服务端本次消息发送时间更新用户端消息接收时间。
9.一种用户端的消息传输处理***，其特征在于，包括：
消息接收模块，用于接收服务端发送的消息，其中，所述服务端发送的消息中包括服务端本次消息发送时间和服务端上一次消息发送时间；
重传请求模块，用于根据所述服务端本次消息发送时间更新用户端消息接收时间，并将所述服务端上一次消息发送时间与用户端上一次消息接收时间比较，如果二者不相同，则向服务端发送消息重传指令，请求重新发送所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间对所述用户端发送的消息。
10.如权利要求9所述的用户端的消息传输处理***，其特征在于，所述重传请求模块判断所述服务端上一次消息发送时间是否为0，如果是，则直接保存所述消息，并根据所述服务端本次消息发送时间更新用户端消息接收时间。
11.一种消息传输方法，其特征在于，包括以下步骤：
服务端在发送给用户端的消息中添加服务端本次消息发送时间和服务端上一次消息发送时间，将所述消息发送给用户端；
用户端接收服务端发送的消息，并根据所述服务端本次消息发送时间更新用户端消息接收时间，将所述服务端上一次消息发送时间与所述用户端上一次消息接收时间比较，如果二者不相同，则向所述服务端发送消息重传指令，其中，所述消息重传指令包括用户端上一次消息接收时间；
服务端接收到所述消息重传指令时，重新发送所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间对所述用户端发送的消息。
12.一种消息传输***，包括服务端和用户端，其特征在于：
所述服务端用于在发送给用户端的消息中添加服务端本次消息发送时间和服务端上一次消息发送时间，将所述消息发送给用户端；并在接收到用户端发送的消息重传指令时，重新发送所述用户端上一次消息接收时间到所述服务端本次消息发送时间之间对所述用户端发送的消息；
所述用户端用于接收服务端发送的消息，并根据所述服务端本次消息发送时间更新用户端消息接收时间，将所述服务端上一次消息发送时间与所述用户端上一次消息接收时间比较，如果二者不相同，则向所述服务端发送消息重传指令，其中，所述消息重传指令包括用户端上一次消息接收时间。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201310713569.8A CN103684707B (zh) | 2013-12-20 | 2013-12-20 | 服务端、用户端消息传输处理方法、消息传输方法及*** |
| PCT/CN2014/094240 WO2015090218A1 (zh) | 2013-12-20 | 2014-12-18 | 服务端、用户端消息传输处理方法、消息传输方法及*** |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201310713569.8A CN103684707B (zh) | 2013-12-20 | 2013-12-20 | 服务端、用户端消息传输处理方法、消息传输方法及*** |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN103684707A CN103684707A (zh) | 2014-03-26 |
| CN103684707B true CN103684707B (zh) | 2017-02-15 |
Family
ID=50321112
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201310713569.8A Active CN103684707B (zh) | 2013-12-20 | 2013-12-20 | 服务端、用户端消息传输处理方法、消息传输方法及*** |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN103684707B (zh) |
| WO (1) | WO2015090218A1 (zh) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103684707B (zh) * | 2013-12-20 | 2017-02-15 | 广州华多网络科技有限公司 | 服务端、用户端消息传输处理方法、消息传输方法及*** |
| CN104320224B (zh) * | 2014-10-13 | 2017-09-29 | 北京航天自动控制研究所 | 一种基于1553b总线的可靠性通信方法 |
| CN104954446B (zh) * | 2015-05-28 | 2019-02-12 | 北京中亦安图科技股份有限公司 | 消息推送方法及*** |
| CN107666625B (zh) * | 2017-08-08 | 2019-12-03 | 武汉斗鱼网络科技有限公司 | 一种消息处理方法、装置及电子设备 |
| CN114038229B (zh) * | 2021-10-21 | 2022-09-16 | 青岛海信网络科技股份有限公司 | 一种路侧停车处理方法和设备 |
| CN115103001B (zh) * | 2022-05-10 | 2024-03-08 | 航天国政信息技术(北京)有限公司 | 一种通信方法、装置及电子设备 |
| CN116455527A (zh) * | 2023-06-16 | 2023-07-18 | 深圳华锐分布式技术股份有限公司 | 消息重传方法 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101888602A (zh) * | 2009-05-15 | 2010-11-17 | 华为技术有限公司 | 消息处理装置、方法、消息业务***和消息中心 |
| CN102111348A (zh) * | 2011-03-11 | 2011-06-29 | 华为终端有限公司 | 信息处理方法及装置 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6683850B1 (en) * | 1997-08-29 | 2004-01-27 | Intel Corporation | Method and apparatus for controlling the flow of data between servers |
| CN100442755C (zh) * | 2003-11-14 | 2008-12-10 | 华为技术有限公司 | 一种保证通用路由封装隧道传输可靠的方法 |
| CN101267241A (zh) * | 2007-03-15 | 2008-09-17 | 华为技术有限公司 | 一种中继网络中的自动重传请求方法、***及中继站 |
| CN101383685A (zh) * | 2007-09-07 | 2009-03-11 | 华为技术有限公司 | 下行混合自动重传的方法、***及装置 |
| CN101159520A (zh) * | 2007-10-29 | 2008-04-09 | 中兴通讯股份有限公司 | 数据传输方法 |
| CN102273118B (zh) * | 2011-04-18 | 2016-06-22 | 华为终端有限公司 | 数据重传的方法、装置及*** |
| CN103684707B (zh) * | 2013-12-20 | 2017-02-15 | 广州华多网络科技有限公司 | 服务端、用户端消息传输处理方法、消息传输方法及*** |
-
2013
- 2013-12-20 CN CN201310713569.8A patent/CN103684707B/zh active Active
-
2014
- 2014-12-18 WO PCT/CN2014/094240 patent/WO2015090218A1/zh active Application Filing
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101888602A (zh) * | 2009-05-15 | 2010-11-17 | 华为技术有限公司 | 消息处理装置、方法、消息业务***和消息中心 |
| CN102111348A (zh) * | 2011-03-11 | 2011-06-29 | 华为终端有限公司 | 信息处理方法及装置 |
Non-Patent Citations (2)
| Title |
|---|
| RTP Retransmission Payload Format;J. Rey等;《IETF RFC4588》;20060731;全文 * |
| Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions;E. Blanton等;《IETF RFC3708》;20040229;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2015090218A1 (zh) | 2015-06-25 |
| CN103684707A (zh) | 2014-03-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN103684707B (zh) | 服务端、用户端消息传输处理方法、消息传输方法及*** | |
| US20220014312A1 (en) | Data transmission method and apparatus | |
| KR101594304B1 (ko) | 무선 통신 네트워크에서 다중경로 전송 접속을 위한 동적 서브플로우 제어 | |
| EP2420014B1 (en) | Method of receiving a point-to-multipoint service in a wireless communication system | |
| JP2003521155A (ja) | 無線ネットワーク・システムおよび方法 | |
| US9037935B2 (en) | Apparatus and method for retransmitting message in message transmission system | |
| KR102046792B1 (ko) | 송신 노드로부터 목적지 노드로의 데이터 전송 방법 | |
| CN109076475B (zh) | 一种用于保持无连接传输中同步的方法和*** | |
| US20150071276A1 (en) | System and Method for Performing Hybrid Automatic Repeat Request (HARQ) in a WLAN System | |
| JP2014501059A (ja) | データ再送方法、データ再送装置、およびデータ再送システム | |
| US20160127083A1 (en) | Link Processing in Multipath Transmission Control Protocol and Mobile Terminal | |
| EP2521299A1 (en) | Data transmission method and network side device | |
| US11258721B2 (en) | Radio link control (RLC) acknowledged mode (AM) data reception | |
| WO2011096009A1 (ja) | 無線機器及び無線システム | |
| CN103546245B (zh) | 一种基于网络编码的数据包重传方法 | |
| US20050213533A1 (en) | System and method for transmitting units of messages in a mobile communication system | |
| JP2008053854A (ja) | データの再送方法、通信装置、およびコンピュータプログラム | |
| WO2019042032A1 (zh) | 一种数据传输方法、rlc实体及pdcp实体 | |
| KR100660055B1 (ko) | 무선통신 단말기에서의 패킷 전송 방법 | |
| CN103281369A (zh) | 报文处理方法及广域网加速控制器woc | |
| US20030035407A1 (en) | Packet retransmission in wireless packet data networks | |
| JP4805072B2 (ja) | 通信システム | |
| CN106100797B (zh) | 一种基于ltp异步加速重传策略的深空文件传输方法 | |
| US9794930B1 (en) | Method and apparatus for packet data unit processing for retransmission | |
| US20240073995A1 (en) | Method and apparatus for managing connection |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| EE01 | Entry into force of recordation of patent licensing contract |
Application publication date: 20140326 Assignee: All kinds of fruits garden, Guangzhou network technology company limited Assignor: Guangzhou Huaduo Network Technology Co., Ltd. Contract record no.: 2015990000265 Denomination of invention: Server-side and user-side message transmission processing method, message transmission method and message transmission system License type: Exclusive License Record date: 20150504 |
|
| LICC | Enforcement, change and cancellation of record of contracts on the licence for exploitation of a patent or utility model | ||
| CB02 | Change of applicant information |
Address after: 510655 Guangzhou City, Guangdong Province, Panyu District, South Village, Huambo Business District Wanda Plaza, block B1, floor 28 Applicant after: Guangzhou Huaduo Network Technology Co., Ltd. Address before: 510655, Guangzhou, Tianhe District, Whampoa Avenue, No. 309, creative park, building 3-08 Applicant before: Guangzhou Huaduo Network Technology Co., Ltd. |
|
| COR | Change of bibliographic data | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant |