CN115866286B - Method and system for message service in live broadcast business - Google Patents
Method and system for message service in live broadcast business Download PDFInfo
- Publication number
- CN115866286B CN115866286B CN202310046332.2A CN202310046332A CN115866286B CN 115866286 B CN115866286 B CN 115866286B CN 202310046332 A CN202310046332 A CN 202310046332A CN 115866286 B CN115866286 B CN 115866286B
- Authority
- CN
- China
- Prior art keywords
- message
- service
- messages
- server
- client
- 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
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The application provides a method and a system for message service in live broadcast business. The method comprises the following steps: the server side obtains the cluster information according to the request parameters sent by the client side; returning two cluster addresses to the client according to the cluster information; and respectively establishing two long connections with the two cluster addresses through the client, and sending message data of different message types through the two long connections. The system comprises a server and a client.
Description
Technical Field
The present application relates to the field of communications technology application, and in particular, to a method and system for message service in live broadcast service.
Background
With the rapid rise of the live broadcast industry in recent years, the number of users is also increasing. Live corporate broadcast has become an important form of business marketing and other business applications, including a number of industries, such as medical, educational, financial, and the like. In the live broadcast process, message sending and receiving are indispensable as important tools for tandem live broadcast services. Therefore, it is important to design a set of message services that can support the live high concurrency scenario.
However, the traditional implementation of message services using hypertext preprocessor (PHP, hypertext Preprocessor) language is not capable of meeting the ever-increasing live demand in terms of performance and is also serious in terms of resource waste.
The above information disclosed in the background section is only for enhancement of understanding of the background of the application and therefore it may contain information that does not form the prior art that is already known to a person of ordinary skill in the art.
Disclosure of Invention
In order to solve the above problems, the present application proposes a method and a system for message service in live broadcast service.
According to a first aspect of the present application, a method for message service in live broadcast service is provided, and the method is used for a server, and includes:
acquiring the cluster information according to the request parameters sent by the client;
returning two cluster addresses to the client according to the cluster information;
and respectively establishing two long connections with the two cluster addresses through the client, and sending message data of different message types through the two long connections.
According to some embodiments, the message types include: room messages, custom messages, chat messages, and online and offline messages.
According to some embodiments, the two cluster addresses include a first main address and a second main address, the establishing, by the client, two long connections with the two cluster addresses, respectively, sending message data of different message types via the two long connections, including:
based on the long connection established by the first main address, sending the message with the message type of the room message and the custom message according to a first type message sending mode;
and transmitting the message with the message type of the chat message and the uplink and downlink message according to a second type message transmission mode based on the long connection established by the second main address.
According to some embodiments, in the case of sending a message according to the first type of messaging, the service side includes a first service side providing a long connection service and a second service side providing the message service, where:
the first server is a subscriber, and the second server is a publisher;
the second server receives a message sending request and sends a message;
the first server and the second server use the same set of storage system to communicate and receive the message.
According to some embodiments, the subscriber and the publisher send messages via a transmitter and subscribe to messages via an adapter.
In accordance with some embodiments, in the case of messages sent in the second type of messaging,
the client is a subscriber, and the server is a publisher;
and under the condition that the server receives the request of sending the message sent by the client, sending the message by adopting a short connection request mode.
According to a second aspect of the present application, a method for message service in live broadcast service is provided, for a client, including:
sending a parameter request;
acquiring two cluster addresses returned by the server according to the parameter request;
respectively establishing two long connections according to the two cluster addresses;
and respectively acquiring message data of different message types sent by the server according to the two long connections.
According to some embodiments, the message types include: room messages, custom messages, chat messages, and online and offline messages.
According to some embodiments, the two cluster addresses include a first main address and a second main address, and the obtaining, according to the two long connections, message data of different message types sent by the server side includes:
based on the long connection established by the first main address, receiving the messages with the message types of the room message and the custom message according to a first type message receiving mode;
and receiving the message with the message type of the chat message and the uplink and downlink message according to a second type message receiving mode based on the long connection established by the second main address.
According to a third aspect of the present application, a system for message service in live broadcast service is provided, comprising:
a server for executing the method according to any one of the first aspects;
a client for performing the method of any of the second aspects.
The application provides a method and a system for message service in live broadcast business, wherein the message service is reasonably layered and sub-packaged in a scheme, and different long connection services are adopted for message distribution according to different message types, so that the business use is more reasonable; the message is asynchronously distributed by introducing the RocketMQ message middleware, so that the delay rate of the message can be effectively reduced under a high concurrency scene, and the integral performance of the system is better improved by the advantages of decoupling and flow peak clipping.
The method and the system for message service in live broadcast service are provided, on the architecture design, reasonable directional expansion is carried out according to different requirements of the service, and by adopting a mode of service processing and data processing layering, the number of deployed nodes of different services can be planned more reasonably when the service is deployed, so that the utilization rate of each service is maximized and optimized, and the service deployment cost of enterprises can be reduced better in the enterprise live broadcast industry. In addition, in the implementation process, because of different layering designs between services and in services, the initial deployment node of the service is defined according to service use conditions, and capacity expansion and capacity shrinkage can be carried out according to service growth conditions and the cost is kept to be optimal in the later stage under the scene of message service growth or descending; in coping with different service demands, the expansibility and reusability of the system are more outstanding than those of the system in the traditional mode, and the later service maintainability is stronger. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.
Drawings
The above and other objects, features and advantages of the present application will become more apparent by describing in detail exemplary embodiments thereof with reference to the attached drawings. The drawings described below are only some of the embodiments of the present application and are not intended to limit the present application.
FIG. 1 illustrates a method flow diagram of a message service in live traffic in accordance with an exemplary embodiment;
FIG. 2 illustrates a system diagram of a message service in live traffic in accordance with an exemplary embodiment;
FIG. 3 illustrates an overall architecture diagram of a message service in live traffic in accordance with an exemplary embodiment;
fig. 4 illustrates a connection setup and send message timing diagram of an exemplary embodiment.
Detailed Description
Example embodiments will now be described more fully with reference to the accompanying drawings. However, the exemplary embodiments can be embodied in many forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of the example embodiments to those skilled in the art. The same reference numerals in the drawings denote the same or similar parts, and thus a repetitive description thereof will be omitted.
The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the disclosure. One skilled in the relevant art will recognize, however, that the disclosed aspects may be practiced without one or more of the specific details, or with other methods, components, materials, apparatus, etc. In these instances, well-known structures, methods, devices, implementations, materials, or operations are not shown or described in detail.
The flow diagrams depicted in the figures are exemplary only, and do not necessarily include all of the elements and operations/steps, nor must they be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the order of actual execution may be changed according to actual situations.
The terms first, second and the like in the description and in the claims of the present application and in the above-described figures, are used for distinguishing between different objects and not for describing a particular sequential order. Furthermore, the terms "comprise" and "have," as well as any variations thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those listed steps or elements but may include other steps or elements not listed or inherent to such process, method, article, or apparatus.
Those skilled in the art will appreciate that the drawings are schematic representations of example embodiments, and that the modules or flows in the drawings are not necessarily required to practice the present application, and therefore, should not be taken to limit the scope of the present application.
Fig. 1 shows a flow chart of a method of message service in live traffic in an exemplary embodiment.
S101, the server acquires the cluster information according to the request parameters sent by the client.
According to an example embodiment, after a user enters a live room, a client sends a request parameter to request a server to acquire a cluster address.
According to some embodiments, the server provides different types of messaging modes for different scenes, and the messaging modes are mainly divided into an API and an SDK from a request source, wherein the API mode is a server-to-server mode, and the SDK is a service front-end-to-server mode.
S102, the server returns two cluster addresses to the client according to the cluster information.
According to an example embodiment, the server obtains the current cluster information according to the request parameter, and returns the two cluster addresses, namely the msg main address and the chat main address.
S103, the client establishes two long connections according to the two cluster addresses respectively.
According to an example embodiment, a client establishes long connections with two primary addresses, respectively, through an integrated SDK.
S104, the server sends message data with different message types through two long connections, and the client receives the message data with different message types through the two long connections.
According to an example embodiment, the message types include: room messages, custom messages, chat messages, and online and offline messages.
According to an example embodiment, based on a long connection established by an msg main address, a server sends a message with a message type of room message and a custom message according to a first type message sending mode; based on the long connection established by the chat main address, the server side sends the messages with the message types of chat messages and online and offline messages according to the second type message sending mode.
According to an example embodiment, a client receives messages with message types of room messages and custom messages according to a first type message receiving manner based on a long connection established by an msg main address; based on the long connection established by the chat main address, the client receives the messages with the message types of chat messages and online and offline messages according to the second type message receiving mode.
According to an example embodiment, as shown in fig. 3, the first type of message sending manner includes that the service end performs message pushing and receiving with the client based on the publish-subscribe manner of redis, and when the client establishes a long connection with the service end according to the msg main address, the client performs instant messaging mainly according to another long connection service provided by the platform, and the long connection service and the message service use the same set of redis clusters. The service end comprises a first service end for providing long connection service and a second service end for providing message service, wherein: the first service end is a subscriber, and the second service end is a publisher; the second server receives the message sending request and sends the message.
According to an example embodiment, as shown in fig. 4, when the first server and the second server send and receive messages, the first server and the second server send the messages through a socket.
According to some embodiments, after receiving the request for sending the message, the second server providing the message service uses the SIO transmitter to send the message, if it is a room message or a custom message, and the interior is actually a secondary package of the public command and the sending content of the Redis.
According to some embodiments, as shown in fig. 3, the message sending logic mainly includes: request parameter validity verification, message length verification, application and channel information inspection, message data encapsulation according to different message types, message validity verification, message asynchronous transmission (producer) through a RocketMQ, and interface processing result return.
According to some embodiments, when basic data query verification operations of application information, channel information and the like are referred to in the application, query acquisition is required from a database. The message service is therefore designed in a hierarchical manner, i.e. two layers of traffic handling (message pre-layer) +data handling (message data layer). The message pre-layer is mainly responsible for carrying out business logic arrangement aiming at different interfaces, and when part of logic needs to acquire data from a database, the pre-layer calls the data layer to inquire corresponding data. The data layer only provides service for the front layer in design, and cannot be used outwards, so that the safety of data can be ensured as much as possible.
According to some embodiments, the fact that the RocketMQ performs asynchronous message transmission is introduced because the RocketMQ has the characteristics of service decoupling, high availability, high reliability and the like, so that the asynchronous message transmission is mainly performed in an asynchronous mode when the actual message transmission is performed. I.e. the sending message interface actually acts as the producer of the message pushing the assembled message into the MQ, and the message service then sets different message consumers for the different message types for the actual message sending.
According to an example embodiment, the second type of messaging method includes that, in a case where the message is sent according to the second type of messaging method, the server is implemented based on a Push Stream module of nginnx. When the client SDK establishes long connection with the server according to the chat main address, the client is a subscriber, and the server is a publisher; and under the condition that the server receives a request for sending the message sent by the client, the server sends the message to the pub address of the chat service in a short connection request mode.
The application provides a method for message service in live broadcast business, which is characterized in that the message service is reasonably layered and sub-packaged in scheme, and different long connection services are adopted for message distribution according to different message types, so that the business use is more reasonable; the message is asynchronously distributed by introducing the RocketMQ message middleware, so that the delay rate of the message can be effectively reduced under a high concurrency scene, and the integral performance of the system is better improved by the advantages of decoupling and flow peak clipping.
The method for message service in live broadcast service is provided, reasonable directional expansion is carried out according to different requirements of the service in architecture design, and the number of deployed nodes of different services can be reasonably planned when the services are deployed by adopting a mode of service processing and data processing layering, so that the utilization rate of each service is maximized and optimized, and the service deployment cost of enterprises can be well reduced in the enterprise live broadcast industry. In addition, in the implementation process, because of different layering designs between services and in services, the initial deployment node of the service is defined according to service use conditions, and capacity expansion and capacity shrinkage can be carried out according to service growth conditions and the cost is kept to be optimal in the later stage under the scene of message service growth or descending; in coping with different service demands, the expansibility and reusability of the system are more outstanding than those of the system in the traditional mode, and the later service maintainability is stronger.
Fig. 2 shows a system diagram of a message service in live traffic in accordance with an exemplary embodiment.
As shown in fig. 2, the system for message service in live service includes a client 201 and a server 203.
According to an exemplary embodiment, the client 201 is configured to send a parameter request, and obtain two cluster addresses returned by the server 203 according to the parameter request.
According to some embodiments, after the user enters the live room, the client 201 sends a request parameter to request the server 203 to obtain the cluster address.
According to an example embodiment, the server 203 is configured to obtain the cluster information according to the request parameter sent by the client 201, and return two cluster addresses to the client 201 according to the cluster information.
According to an example embodiment, the server 203 obtains the current cluster information according to the request parameter, and returns the two cluster addresses, the msg main address and the chat main address.
According to some embodiments, the server 203 provides different types of messaging modes for different scenarios, and is mainly divided into an API and an SDK from a request source, where the API mode is a server 203 to a server 203, and the SDK is a service front to a server 203.
According to an exemplary embodiment, the client 201 is configured to establish two long connections from two cluster addresses, respectively.
According to an example embodiment, the client 201 establishes long connections with two primary addresses, respectively, through the integrated SDK.
According to an example embodiment, the server 203 sends message data of different message types via two long connections.
According to an example embodiment, the message types include: room messages, custom messages, chat messages, and online and offline messages.
According to an example embodiment, based on the long connection established by the msg primary address, the client 201 receives messages with message types of room messages and custom messages according to the first type message receiving manner; based on the long connection established by the chat home address, the client 201 receives messages with message types of chat messages and online and offline messages according to the second type message receiving manner.
According to an example embodiment, based on the long connection established by the msg primary address, the server 203 sends a message with a message type of room message and a custom message according to the first type of message sending manner; based on the long connection established by the chat main address, the server 203 sends messages with the message types of chat messages and online and offline messages according to the second type of message sending mode.
According to an exemplary embodiment, the first type of message sending manner includes that the server 203 performs message pushing and receiving with the client 201 based on the redis publish-subscribe manner, and when the client 201 establishes a long connection with the server 203 according to the msg main address, the long connection service is mainly performed according to another long connection service provided by the platform, and the long connection service and the message service perform instant messaging by using the same set of redis clusters. The service side 203 includes a first service side providing a long connection service and a second service side providing a message service, wherein: the first service end is a subscriber, and the second service end is a publisher; the second server receives the message sending request and sends the message.
According to an example embodiment, when the first server and the second server send and receive messages, the first server and the second server send the messages through a Socket Io (SIO) transmitter, and subscribe the messages through a Socket Io (SIO) adapter.
According to some embodiments, after receiving the request for sending the message, the second server providing the message service uses the SIO transmitter to send the message, if it is a room message or a custom message, and the interior is actually a secondary package of the public command and the sending content of the Redis.
According to an exemplary embodiment, the second type of messaging method includes that, in the case of sending a message according to the second type of messaging method, the server 203 is implemented based on the nginnx Push Stream module. When the client 201SDK establishes long connection with the server 203 according to the chat main address, the client 201 is a subscriber, and the server 203 is a publisher; in the case where the server 203 receives a request for sending a message sent by the client 201, the server 203 sends the message to the pub address of the chat service by using a short connection request method.
According to some embodiments, when basic data query verification operations of application information, channel information and the like are referred to in the application, query acquisition is required from a database. The message service is therefore designed in a hierarchical manner, i.e. two layers of traffic handling (message pre-layer) +data handling (message data layer). The message pre-layer is mainly responsible for carrying out business logic arrangement aiming at different interfaces, and when part of logic needs to acquire data from a database, the pre-layer calls the data layer to inquire corresponding data. The data layer only provides service for the front layer in design, and cannot be used outwards, so that the safety of data can be ensured as much as possible.
The application provides a system for message service in live broadcast business, which is characterized in that the message service is reasonably layered and sub-packaged in scheme, and different long connection services are adopted for message distribution according to different message types, so that the business use is more reasonable; the message is asynchronously distributed by introducing the RocketMQ message middleware, so that the delay rate of the message can be effectively reduced under a high concurrency scene, and the integral performance of the system is better improved by the advantages of decoupling and flow peak clipping.
The system for message service in live broadcast service is provided, on the architecture design, reasonable directional expansion is carried out according to different requirements of the service, and by adopting a mode of service processing and data processing layering, the number of deployed nodes of different services can be reasonably planned during service deployment, so that the utilization rate of each service is maximized and optimized, and the service deployment cost of enterprises can be well reduced in the enterprise live broadcast industry. In addition, in the implementation process, because of different layering designs between services and in services, the initial deployment node of the service is defined according to service use conditions, and capacity expansion and capacity shrinkage can be carried out according to service growth conditions and the cost is kept to be optimal in the later stage under the scene of message service growth or descending; in coping with different service demands, the expansibility and reusability of the system are more outstanding than those of the system in the traditional mode, and the later service maintainability is stronger.
It should be clearly understood that this application describes how to make and use particular examples, but is not limited to any details of these examples. Rather, these principles can be applied to many other embodiments based on the teachings of the present disclosure.
Furthermore, it should be noted that the above-described figures are merely illustrative of the processes involved in the method according to the exemplary embodiments of the present application, and are not intended to be limiting. It will be readily appreciated that the processes shown in the above figures do not indicate or limit the temporal order of these processes. In addition, it is also readily understood that these processes may be performed synchronously or asynchronously, for example, among a plurality of modules.
Exemplary embodiments of the present application are specifically illustrated and described above. It is to be understood that this application is not limited to the details of construction, arrangement or method of implementation described herein; on the contrary, the application is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.
Claims (6)
1. A method for message service in live broadcast service, which is used for a service end and comprises the following steps:
acquiring the cluster information according to the request parameters sent by the client;
returning two cluster addresses to the client according to the cluster information;
establishing two long connections with the two cluster addresses respectively through the client, and sending message data of different message types through the two long connections:
the two cluster addresses include an msg main address and a chat main address, and the message types include: room messages, custom messages, chat messages, and online and offline messages;
based on the long connection established by the msg main address, sending the message with the room message and the custom message according to a first type message sending mode;
and transmitting messages with the message types of chat messages and online and offline messages according to a second type message transmission mode based on the long connection established by the chat main address.
2. The method of message service in live service according to claim 1, wherein in case of transmitting a message according to the first type of message transmission mode, the service side includes a first service side providing a long connection service and a second service side providing the message service, wherein:
the first server is a subscriber, and the second server is a publisher;
the second server receives a message sending request and sends a message;
the first server and the second server use the same set of storage system to communicate and receive the message.
3. The method of message service in live traffic of claim 2, wherein the subscriber and the publisher perform message transmission through a transmitter and subscription of messages through an adapter.
4. A method for message service in a live service as defined in claim 1, wherein, in the case of transmitting a message in accordance with the second type of messaging,
the client is a subscriber, and the server is a publisher;
and under the condition that the server receives the request of sending the message sent by the client, sending the message by adopting a short connection request mode.
5. A method for message service in live broadcast service, characterized by comprising:
sending a parameter request;
acquiring two cluster addresses returned by the server according to the parameter request;
respectively establishing two long connections according to the two cluster addresses;
respectively acquiring message data of different message types sent by the server according to the two long connections:
the two cluster addresses include an msg main address and a chat main address, and the message types include: room messages, custom messages, chat messages, and online and offline messages;
based on the long connection established by the msg main address, receiving the message with the message type of room message and custom message according to a first type message receiving mode;
and receiving messages with the message types of chat messages and online and offline messages according to a second type message receiving mode based on the long connection established by the chat main address.
6. A system for message service in live traffic, comprising:
a server for executing the method according to any one of claims 1-4;
a client for performing the method of claim 5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310046332.2A CN115866286B (en) | 2023-01-31 | 2023-01-31 | Method and system for message service in live broadcast business |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310046332.2A CN115866286B (en) | 2023-01-31 | 2023-01-31 | Method and system for message service in live broadcast business |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115866286A CN115866286A (en) | 2023-03-28 |
| CN115866286B true CN115866286B (en) | 2023-05-16 |
Family
ID=85657380
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310046332.2A Active CN115866286B (en) | 2023-01-31 | 2023-01-31 | Method and system for message service in live broadcast business |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115866286B (en) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9083770B1 (en) * | 2013-11-26 | 2015-07-14 | Snapchat, Inc. | Method and system for integrating real time communication features in applications |
| WO2020211344A1 (en) * | 2019-04-17 | 2020-10-22 | 平安科技（深圳）有限公司 | Mqtt-based message distribution method, server, apparatus, and storage medium |
| CN112084042A (en) * | 2019-06-13 | 2020-12-15 | 北京京东振世信息技术有限公司 | Message processing method and device |
| CN112511628A (en) * | 2020-11-30 | 2021-03-16 | 银盛支付服务股份有限公司 | Distributed real-time message pushing method |
| CN113132487A (en) * | 2021-04-21 | 2021-07-16 | 深圳市乐唯科技开发有限公司 | Simplified distributed long-connection data transmission method and system |
-
2023
- 2023-01-31 CN CN202310046332.2A patent/CN115866286B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9083770B1 (en) * | 2013-11-26 | 2015-07-14 | Snapchat, Inc. | Method and system for integrating real time communication features in applications |
| WO2020211344A1 (en) * | 2019-04-17 | 2020-10-22 | 平安科技（深圳）有限公司 | Mqtt-based message distribution method, server, apparatus, and storage medium |
| CN112084042A (en) * | 2019-06-13 | 2020-12-15 | 北京京东振世信息技术有限公司 | Message processing method and device |
| CN112511628A (en) * | 2020-11-30 | 2021-03-16 | 银盛支付服务股份有限公司 | Distributed real-time message pushing method |
| CN113132487A (en) * | 2021-04-21 | 2021-07-16 | 深圳市乐唯科技开发有限公司 | Simplified distributed long-connection data transmission method and system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115866286A (en) | 2023-03-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR20190030116A (en) | Micro grid energy management system using dds middleware | |
| CN101257460A (en) | Instantaneous message temporary cluster group conversational system and method for creating and transmitting instantaneous message | |
| CN112055078B (en) | Data transmission method, device, computer equipment and storage medium | |
| CN114338063B (en) | Message queue system, service processing method and computer readable storage medium | |
| CN108289055B (en) | Distributed real-time chat system and method based on Redis subscription service | |
| CN104320441A (en) | Method of sharing information between wireless communication systems | |
| CN112527523A (en) | Distributed message transmission method and system for high-performance computing multiple clouds | |
| CN109510748B (en) | Node and node interaction method and system | |
| CN115866286B (en) | Method and system for message service in live broadcast business | |
| CN113472848A (en) | Network fusion method and device of virtual machine and container and related equipment | |
| CN111737029A (en) | Server, data pushing method and data pushing system | |
| US11337038B2 (en) | Method, device and system for transmitting multicast group information | |
| CN101150443B (en) | Processing method for telecommunication network management message | |
| CN111866170B (en) | Method for transmitting synchronous message in IOT cluster | |
| CN101925021B (en) | Method/system for processing messages and convergence service system | |
| CN107423131B (en) | Sharing method and server | |
| CN113242313B (en) | Data synchronization method, system, device, server and storage medium | |
| CN101729434A (en) | Method for realizing message interaction and convergence service system | |
| CN100502301C (en) | Node controlling method in network management system | |
| CN110474781B (en) | Method and device for forwarding multicast data | |
| CN113641400A (en) | Method for sharing micro-service public resource by multi-version service, API gateway and management system | |
| CN111479211A (en) | Subscription control method and system for terminal positioning information | |
| CN114501595B (en) | 5G networking engineering management system | |
| CN113709234B (en) | Service providing method and service function entity | |
| CN112637044A (en) | Message cross-region forwarding system and method based on remote service |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |