CN114679436A

CN114679436A - Session management method, server and computer readable storage medium

Info

Publication number: CN114679436A
Application number: CN202210585986.8A
Authority: CN
Inventors: 张凯; 李兴宗; 王洵; 罗伦文; 谭军胜; 任明; 朱博
Original assignee: Wuhan Zhongke Tongda High New Technology Co Ltd
Current assignee: Wuhan Zhongke Tongda High New Technology Co Ltd
Priority date: 2022-05-27
Filing date: 2022-05-27
Publication date: 2022-06-28
Anticipated expiration: 2042-05-27
Also published as: CN114679436B

Abstract

The embodiment of the application provides a session management method, a server and a computer readable storage medium, wherein the part related to session processing between data acquisition equipment and a request end is divided into three different session modules, different session processing is carried out through the different session modules, the functions of the modules are independent, the coupling is extremely low, and the coupling between the session modules is reduced; secondly, the communication between the modules is only to send the corresponding request object to the queue corresponding to the next module, the communication is simple, and the conversation processing and communication are carried out in a thread mode, so that the asynchronous communication between the modules is realized, and the stability of the whole conversation process and the safety of the conversation are ensured; in addition, when the service session is generated, one device identifier is generated according to the device identifiers, and when the device identifiers are the same, a plurality of request terminals can share one service session, so that the session efficiency is improved.

Description

Session management method, server and computer readable storage medium

Technical Field

The present application relates to the field of intelligent traffic technologies, and in particular, to a session management method, a server, and a computer-readable storage medium.

Background

The video monitoring system is based on GB/T28181 (national standard, information transmission, exchange and control technical requirements of a safety and protection video monitoring networking system) standard. In a video monitoring system, when a platform or a user end of a third party needs to acquire data (such as video, audio and image data of a national standard camera) of a monitoring device, a session with the monitoring device needs to be established, and for the monitoring device, a session is established one at a time. When a plurality of platforms or clients needing to access the monitoring device exist, a plurality of sessions are established at one time, which causes network congestion, and how to efficiently manage the sessions between the plurality of platforms or clients and the monitoring device is an urgent problem to be solved.

Disclosure of Invention

Embodiments of the present application provide a session management method, a server, and a computer-readable storage medium, which reduce coupling between modules corresponding to session management, and improve efficiency and session stability of session management.

The embodiment of the application provides a session management method, which is applied to a server, wherein the server comprises a user mode session module, a service session module and an SIP session module, and the session management method comprises the following steps:

receiving a session request from a request terminal through a user mode message queue of the user mode session module, wherein the session request is used for requesting a session with data acquisition equipment, and the session request comprises a request identifier of the request terminal and an equipment identifier of the data acquisition equipment;

acquiring the session request from the user state message queue according to the user state session thread of the user state session module, generating a serialized request object corresponding to the session request according to the request identifier, and sending the serialized request object to the serialized message queue of the service session module;

acquiring the serialized request object from the serialized message queue according to a service session thread of the service session module, and detecting whether a service session corresponding to the equipment identifier exists or not according to the equipment identifier in the serialized request object;

if the SIP request object does not exist, generating a service session corresponding to the equipment identifier, generating an SIP request object corresponding to the equipment identifier according to the service session, and sending the SIP request object to an SIP object pool of an SIP session module;

and acquiring the SIP request object from the SIP object pool according to the SIP session thread of the SIP session module, and sending the SIP request object to the data acquisition equipment corresponding to the equipment identifier through an SIP protocol stack.

Meanwhile, an embodiment of the present application further provides a server, including: the system comprises a user state session module, a service session module and an SIP session module;

the user mode session module is used for receiving a session request from a request end through a user mode message queue, the session request is used for requesting a session with data acquisition equipment, and the session request comprises a request identifier of the request end and an equipment identifier of the data acquisition equipment; acquiring the session request from the user state message queue according to the user state session thread of the user state session module, generating a serialized request object corresponding to the session request according to the request identifier, and sending the serialized request object to the serialized message queue of the service session module;

the service session module is configured to obtain the serialized request object from the serialized message queue through a service session thread of the service session module, and detect whether a service session corresponding to the device identifier exists according to the device identifier in the serialized request object; if the SIP request object does not exist, generating a service session corresponding to the equipment identifier, generating an SIP request object corresponding to the equipment identifier according to the service session, and sending the SIP request object to an SIP object pool of an SIP session module;

and the SIP session module is used for acquiring the SIP request object from the SIP object pool through the SIP session thread of the SIP session module and sending the SIP request object to the data acquisition equipment corresponding to the equipment identifier through an SIP protocol stack.

Meanwhile, the embodiment of the application also provides a server, which comprises one or more processors; a memory; and one or more computer programs, wherein the processor is coupled to the memory, the one or more computer programs being stored in the memory and configured to be executed by the processor to perform the session management method described above.

Meanwhile, an embodiment of the present application provides a computer-readable storage medium, where a plurality of instructions are stored in the computer-readable storage medium, and the instructions are loaded by a processor to execute the steps in the session management method.

Drawings

The technical solution and other advantages of the present application will become apparent from the detailed description of the embodiments of the present application with reference to the accompanying drawings.

Fig. 1 is a scene schematic diagram of a session management method according to an embodiment of the present application.

Fig. 2 is a flowchart illustrating a session management method according to an embodiment of the present application.

Fig. 3 is a schematic diagram of a user mode session module according to an embodiment of the present application.

Fig. 4 is a schematic diagram of a service session module according to an embodiment of the present application.

Fig. 5 is a schematic diagram of a SIP session module according to an embodiment of the present application.

Fig. 6 is a flowchart of a session management method according to an embodiment of the present application.

Fig. 7 is another schematic flow chart of a session management method according to an embodiment of the present application.

Fig. 8 is a schematic flowchart of a session management method according to an embodiment of the present application.

Fig. 9 is a schematic structural diagram of a server according to an embodiment of the present application.

Fig. 10 is another schematic structural diagram of a server according to an embodiment of the present application.

Fig. 11 is a schematic diagram of connection pool handle description information provided in an embodiment of the present application.

Fig. 12 is a schematic diagram of a service session according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. It is to be understood that the embodiments described are only a few embodiments of the present application and not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

The embodiment of the application provides a session management method, a session management device, a server and a computer readable storage medium. Any one of the session management methods and the session management apparatus provided by the embodiments of the present application may be integrated in a server. The server can be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, and can also be a cloud server for providing basic cloud computing services such as cloud service, a cloud database, cloud computing, cloud functions, cloud storage, network service, cloud communication, middleware service, domain name service, security service, CDN (content delivery network) and big data and artificial intelligence platforms.

Referring to fig. 1, fig. 1 is a schematic view of a scenario of a session management method according to an embodiment of the present application, where the scenario includes multiple request terminals, a server, and multiple data acquisition devices. The client includes but is not limited to a smart phone, a tablet Computer, a notebook Computer, a smart television, an intelligent robot, a Personal Computer (PC), a wearable device, a server Computer, and the like, the data acquisition device may be a data acquisition platform/system, and may also be a camera for acquiring data, wherein the camera includes but is not limited to an embedded high definition camera, a fisheye camera, and the like.

The plurality of request terminals, the server and the plurality of data acquisition devices are located in a wireless network or a wired network, the plurality of data acquisition devices are communicated with the server based on a national standard protocol such as an SIP (session initiation protocol), and the plurality of request terminals can be communicated with the server based on an Internet protocol such as an http (hyper text transport protocol) or a websocket protocol. The request end sends the session request to the server, a plurality of session modules of the server perform a series of processing, and information corresponding to the session request is sent to corresponding data acquisition equipment so as to establish a session with the data acquisition equipment and further acquire data acquired by the data acquisition equipment.

The following describes the session management method, apparatus, server and storage medium in the embodiments of the present application in detail, and it should be noted that the following description of the embodiments is not intended to limit the preferred order of the embodiments.

Fig. 2 is a flowchart illustrating a session management method provided in an embodiment of the present application, where the session management method is applicable to a server, where the server includes a user mode session module, a service session module, and an SIP session module, and the session management method includes the following steps.

101, receiving a session request from a request terminal through a user mode message queue of a user mode session module, where the session request is used to request a session with a data acquisition device, and the session request includes a request identifier of the request terminal and a device identifier of the data acquisition device.

The user mode conversation module is used for processing the conversation request from the request end, such as the conversation request 1, … …, the conversation request N, and the like, and comprises a user mode message queue and a user mode conversation thread pool group, wherein the user mode conversation thread pool group comprises a plurality of user mode conversation threads, such as the user mode conversation threads 1, … …, and the user mode conversation thread N1, as shown in FIG. 3.

And receiving a session request from a request end through a user mode session module, and putting the session request into a user mode message queue. The session request is used for requesting a session with the data acquisition equipment, and the session request comprises a request identifier of a request end and an equipment identifier of the data acquisition equipment. The request identifier of the request end comprises identification information such as an ID number and/or an MAC address and/or an IP address of equipment corresponding to the request end, and the equipment identifier of the data acquisition equipment comprises identification information such as a corresponding equipment ID number and/or an IP address. The session request may be a TCP request from a requesting end, and the session request may be a request in a binary format.

The session requests from the request terminals are put into the user mode message queue, and the session requests from the request terminals are received through the user mode message queue, so that the user mode session module can receive the session requests from different request terminals, and each session request is processed, thereby reducing the possibility that the session requests are lost because the session requests are not processed for a long time, and improving the stability of the session.

The session request of the request end may be a real-time session requesting for a data acquisition device, and correspondingly, the real-time session is used to obtain data acquired by the data acquisition device in real time, or may be a historical session requesting for the data acquisition device, and correspondingly, the historical session is used to obtain data acquired by the data acquisition device in history, or may be a subscription session requesting for a subscription message of the data acquisition device, and correspondingly, the subscription session is used to actively notify the request end when the data acquisition device changes, such as the longitude and latitude of the data acquisition device changes. As shown in particular in figure 3.

102, obtaining a session request from a user state message queue according to a user state session thread of a user state session module, generating a serialized request object corresponding to the session request according to a request identifier, and sending the serialized request object to a serialized message queue of a service session module.

When the user mode message queue is not empty, a plurality of user mode conversation threads of the user mode conversation module can continuously acquire conversation requests from the user mode message queue. For example, after the user-mode conversation thread 1 processes one conversation request, the next conversation request is obtained from the user-mode message queue for processing, and so on for each of the other user-mode conversation threads.

The processing logic of each user-mode conversation thread includes: obtaining a session request from the user mode message queue, generating a serialized request object corresponding to the session request according to the request identifier of the session request, and sending the serialized request object to the serialized message queue of the service session module.

The step of generating the serialized request object corresponding to the session request according to the request identifier of the session request includes: and generating connection pool handle description information corresponding to the session request by using the user mode session thread according to the request identifier, and performing first serialization on the session request according to the connection pool handle description information to obtain a serialized request object corresponding to the session request.

And generating connection pool handle description information corresponding to the session request by using the user mode session thread according to the request identifiers, wherein one request identifier corresponds to one connection pool handle description information, namely one request end corresponds to one connection pool handle description information.

Because one request end corresponds to one connection pool handle description information, no matter how many session requests are sent by one request end, the request end corresponds to one connection pool handle description information. In this way, sessions of different requesters run independently, for example, connection pool handle description information 1 corresponds to a real-time session, and connection pool handle description information 2 corresponds to a real-time session, but the two real-time sessions can be executed in different threads without interference because the sessions correspond to different requesters. Therefore, for each connection pool handle description information, only all the sessions of the corresponding request end need to be managed, and no relation exists between the connection pool handle description information and the sessions of other request ends, so that the situation that the sessions of two different request ends compete in the prior art is avoided. For example, there are a request end a and a request end B, where the request end a and the request end B correspond to 10 sessions respectively, and then the request end a and the request end B manage their internal 10 sessions, and there is no contention between the 10 sessions of the request end a and the 10 sessions of the request end B.

In an embodiment, as shown in fig. 11, a schematic view of connection pool handle description information provided in this embodiment is provided, where the connection pool handle description information includes information such as an atomic serial number, a network communication handle, a session module group, a subscription module group, a cloud control module group, a storage module, and other service modules.

Wherein, the atomic sequence number is specific to the connection pool handle description information or specific to the request end, and the atomic sequence number is unique and can be represented by a positive integer. When a request end is connected to the server, an atomic sequence number is determined in the generated connection pool handle description information, for example, if the atomic sequence number is 6 before the connection pool handle description information of the session request is generated, the atomic sequence number in the connection pool handle description information of the session request is 7. Wherein, after the request end is connected with the server, the atomic sequence number is increased by one. And after the communication connection between the request terminal and the server is disconnected, changing the atomic sequence number in the corresponding connection pool handle description information, such as adding one to the atomic sequence number. The purpose of the atomic sequence number is that after all logics of the session request are processed, when a session response comes back, whether the corresponding request end is still online or not can be determined according to the atomic sequence number, if the corresponding request end is still online, the atomic sequence number is kept unchanged, and if the corresponding request end is disconnected, the atomic sequence number is different from the atomic sequence number in the session response.

The network communication handle corresponds to a network communication link between the request terminal and the server, and the session response can be returned to the corresponding request terminal through the network communication handle. The session module group corresponds to a service session module, the subscription module group corresponds to a subscription session module, the cloud control module group corresponds to a cloud control session module and the like, wherein the session module group, the subscription module group, the cloud control module group and the like do not relate to the overlapping of service logics and can independently process the service logics of the session module group, the subscription module group, the cloud control module group and the like. However, it should be noted that the memory areas operated by the session module group, the subscription module group, and the cloud control module group are absolutely independent and do not overlap. The following description takes the service session module (corresponding to the session module group) as an example, and does not refer to the subscription module group and the cloud control module group.

After the connection pool handle description information is obtained, a first serialization (for example, encapsulation) is performed on the session request according to the connection pool handle description information, so that a serialization request object corresponding to the session request is obtained. For example, the connection pool handle description information is mapped to a connection pool handle, the connection pool handle corresponds to a pointer, points to the connection pool handle description information, obtains an atomic sequence number and a device identifier, such as a device ID, in the connection pool handle description information, and encapsulates the connection pool handle, the atomic sequence number, and the device identifier information to obtain a serialized request object corresponding to the session request. This step may enable encapsulation of the session request according to the connection pool handle description information to encapsulate the session request as a serialized request object. If the session request is in binary format, the encapsulated serialized request object is also in binary format.

After the session request is packaged into the serialized request object, the serialized request object is conveniently and uniformly managed, and the data volume corresponding to the serialized request object is less so as to reduce the storage volume of the service session module.

And after the serialized request object is obtained, sending the serialized request object to a serialized message queue of the service session module.

103, acquiring a serialized request object from the serialized message queue according to the service session thread of the service session module, and acquiring the device identifier in the serialized request object.

The service session module includes a serialized message queue, a service session thread pool and a service session group. The serialized message queue is used for receiving the serialized request object from the user mode session module and the serialized response object from the SIP session module, and the serialized request object and the serialized response object are placed in the serialized message queue, so that the possibility that the serialized request object and the serialized response object are lost due to the fact that the serialized request object and the serialized response object are not processed for a long time is avoided, and the stability of the session is improved. The service session thread pool comprises a plurality of service session threads, such as service session thread 1, … …, user state session thread N2, as shown in FIG. 4. A plurality of service sessions (serverdialogs) in the service session group, which will be described in detail later.

When the serialized message queue is not empty, a plurality of service session threads of the service session module can continuously acquire the serialized request object from the serialized message queue and process the serialized request object.

The service session thread obtains the serialized request object from the serialized message queue and obtains the device identifier in the serialized request object.

And 104, detecting whether the service session corresponding to the equipment identification exists.

Before detecting whether the service session corresponding to the device identifier exists, a service session group in the following embodiment of the present application is introduced.

The service session groups in the embodiment of the present application include three groups, which are respectively total, uesd and free, where total represents all service session groups, uesd represents a service session group in use and corresponds to a video being viewed, and free represents an available and free service session group. Generally, after the service session in use is used, the user enters an idle service session group.

When the server starts to operate, a preset number of service sessions are allocated/created at one time, and all the allocated service sessions are added into an idle service session group corresponding to free. And determining the idle service session from free each time when the service session corresponding to the equipment identifier is generated, and when the free has no idle service session, reestablishing the service session and adding the newly established service session into the total and used. Thus, the service sessions in the total are only increased and not decreased. The service session group is designed in such a way as to avoid frequent new service sessions, deletion/recovery of service sessions, and generation of a large amount of memory fragmentation (with other advantages as will be described later in relation to the related art).

The design of each service session may be as shown in fig. 12, among others. Each service session includes fields for a device identification (e.g., device ID), a SIP session identification (e.g., SIP session ID), a session state (status code), a request list, a media address (e.g., IP address of a media server), an RTP port, a P2P port, etc. The request list may include a plurality of serialized request object information, where each serialized request object information includes an atomic sequence number and a connection pool handle, that is, the request list includes a plurality of atomic sequence numbers and a plurality of corresponding connection pool handles.

Correspondingly, the step of detecting whether the service session corresponding to the device identifier exists is to detect whether the service session corresponding to the device identifier (e.g., the device identifier in the session request, such as the device ID) exists in the uesd. Specifically, the device identifier in the session request is matched with the device identifier of each service session in the used, if the matching is successful, it means that the service session corresponding to the device identifier exists, and if the matching is unsuccessful, it means that the service session corresponding to the device identifier does not exist.

If the service session corresponding to the device identifier does not exist, step 105 is executed, and if the service session corresponding to the device identifier exists, step 107 is executed.

And 105, generating a service session corresponding to the equipment identifier, and sending the SIP request object to an SIP object pool of the SIP session module according to the SIP request object corresponding to the service session generating equipment identifier.

If the preset number of service sessions are not created in the server in advance, that is, no service session group exists, the server may generate a corresponding service session according to the device identifier in the serialized request object after receiving the serialized request object. After the corresponding service session thread acquires the serialized request object from the serialized message queue, acquiring a corresponding service session field in the table 2; sending a port acquisition request to a media server, wherein the port acquisition request is used for acquiring a media address, an RTP port and a P2P port of the media server, the media server receives data acquired by data acquisition equipment through the RTP port, and the data acquired by the data acquisition equipment is distributed to a request end through the P2P port; acquiring a device identifier, an atomic sequence number and a connection pool handle in a serialized request object, and acquiring that a session state is an initial state; in this manner, a service session corresponding to the device identification is generated according to the service session field and the content corresponding to the service session field.

If a service session group exists in the server, the step of generating a service session corresponding to the device identifier includes: determining an idle service session from the set of idle service sessions; filling the equipment identifier and the request list in the service session according to the serialized request object, and updating the session state in the service session to obtain the service session corresponding to the equipment identifier; the service session is added to the group of service sessions being used.

Determining an idle service session from free, acquiring a media address, an RTP port and a P2P port of a media server according to a port acquisition request, filling corresponding fields in the service session by using the acquired media address, RTP port and P2P port, filling corresponding fields in the service session according to a device identifier in a serialized request object, filling corresponding fields in a request list in the service session according to an atomic sequence number and a connection pool handle in the serialized request object, updating a session state field in the service session to be an initial state to obtain a service session corresponding to the device identifier, and adding the service session to used.

The method comprises the steps of directly determining an idle service session from free, filling the service session, and accordingly only updating the content of a field corresponding to the service session, namely simply changing the operation of a section of memory, utilizing a CPU to the maximum extent, wherein the execution speed of the operation of changing the memory is high and is higher than the execution speed of a user mode session thread and the execution speed of an SIP session thread. That is, the design of the service session group can reduce memory fragments, and can generate a corresponding service session by simply changing the operation of a section of memory, thereby increasing the speed of generating the service session.

For example, a request end a requests a video (device id a), a request end B also requests a video (device id a), but both the request end a and the request end B request: the videos of the campus are communicated, so that for the SIP session module, the videos require the same video acquired by the data acquisition equipment with the same equipment identifier, only one SIP session needs to be maintained, two SIP sessions do not need to be maintained, for the service session module, only one service session needs to be maintained, two service sessions do not need to be maintained simultaneously, namely when the equipment identifiers are the same, a plurality of request terminals can share one service session and the corresponding SIP session, all serialized message objects of the data of the same data acquisition equipment, which are requested by the plurality of request terminals, are uniformly managed, and the session efficiency is improved. Correspondingly, the serialized message object information corresponding to the request end A and the request end B is stored in a request list of the service session.

After a service session is generated, then the service session thread needs to send a SIP invite request (session invite request) to the data collection device, and it takes time for this session invite to get through, which is one of the reasons why the request list is designed in the re-service session. Specifically, the step of generating an SIP request object corresponding to the device identifier according to the service session (the function completed by the SIP request object is equivalent to an SIP invite request) includes: and acquiring a session state of the service session, and performing first format conversion on the serialized request object when the session state is a preset state so as to generate an SIP request object corresponding to the equipment identifier.

When the session state of the service session is the initial state, performing first format conversion on the serialized request object, and generating an SIP request object in an SIP format through the first format conversion. In one embodiment, the SIP request object may be a request object that conforms to the GB/T28181 national standard format. In other embodiments, the SIP request object may also be a request object that does not conform to the national standard of GB/T28181, which is described in the following of the present application as an example, for example, although the SIP request object is in the SIP format, the SIP request object differs from the format corresponding to GB/T28181, wherein the protocol relied on by the data acquisition device is GB/T28181, the protocol is a standard specification established by a public security company in conjunction with a domestic head monitoring device manufacturer, and has a certain difficulty in understanding, and the SIP request object also needs to be managed in the SIP session module, so as to facilitate understanding and management, reduce the difficulty in learning, and obtain a colloquially and easily understood SIP request object through the first format conversion.

And after the SIP request object corresponding to the equipment identifier is obtained, the SIP request object is sent to an SIP object pool of an SIP session module, wherein the SIP request object comprises the SIP session identifier, an atomic serial number and the like. After the SIP request object is sent, updating an SIP session identification field in the service session according to an SIP session identification, such as an SIP session ID, in the SIP request object; while updating the session state in the service session to in-process.

It should be noted that the service session module shown in fig. 4 is only an exemplary illustration of a specific module, and a plurality of modules similar to the service session module may also be provided in the server according to different services, for example, one service session module may be created for a real-time session, another service session module may be created for a historical session, another service session module may be created for another session, and so on, which are designed to avoid overlapping of services, reduce coupling between modules, and in addition, achieve high extensibility of services in the server; meanwhile, due to the independence of the services, a plurality of services can be developed in parallel.

And 106, acquiring the SIP request object from the SIP object pool according to the SIP session thread of the SIP session module, and sending the SIP request object to the data acquisition equipment corresponding to the equipment identifier through the SIP protocol stack.

The SIP session module comprises a SIP object pool, a SIP session thread pool group and a SIP format instruction queue. The SIP object pool is used for receiving an SIP request object from the service session module and an SIP response object from the SIP protocol stack, and the SIP request object and the SIP response object are put into the SIP object pool, so that the possibility that the SIP request object and the SIP response object are lost because the SIP request object and the SIP response object are not processed for a long time is avoided, and the stability of the session is improved; the SIP conversation thread pool group comprises a plurality of SIP conversation threads, such as SIP conversation threads 1 and … … and a SIP conversation thread N3, which is shown in FIG. 5; the SIP format instruction queue is used for receiving SIP format instructions sent by the SIP conversation thread.

Compared with the user-mode conversation thread group, the SIP conversation thread group in the SIP conversation thread pool group is far more than the user-mode conversation thread group, that is, the user-mode conversation thread group is lightweight, and the SIP conversation thread pool group is heavyweight, because the user-mode thread pool group may process several or tens of concurrent conversation requests at the same time, the server has extremely low processing pressure, and the number of the concurrences involved in the SIP conversation thread pool group is very large, for example, the number of the data acquisition devices in a certain area can be thousands or even more, so the SIP conversation thread pool group needs to process the simultaneous access of thousands or tens of thousands of data acquisition devices at one time (store the data acquired by the data acquisition devices, etc.). For example, if the access number is 7000, the simultaneous access of 7000 data acquisition devices is processed at one time, and the number of concurrent accesses is increased by hundreds to thousands of times.

When the SIP object pool is not empty, a plurality of SIP session threads of the SIP session module can continuously acquire SIP objects (including SIP response objects, SIP request objects, and the like) from the SIP object pool and perform a series of logic processing on the SIP objects.

In an embodiment, the step of sending the SIP request object to the data acquisition device corresponding to the device identifier through the SIP protocol stack includes: after the SIP request object is obtained through the SIP session thread, the SIP request object is packaged into an SIP format instruction; sending an SIP format instruction to an SIP format instruction queue; and acquiring the SIP format instruction from the SIP format instruction queue through an SIP protocol stack, and sending the SIP format instruction to the data acquisition equipment corresponding to the equipment identifier.

Since the SIP request object is a popular and easy-to-understand request object, the SIP request object is packaged, and specifically, the SIP request object is converted into an SIP format instruction (e.g., a command) of an SIP response, so that the SIP protocol stack reads and sends the SIP format instruction to the data acquisition device. After the SIP format instruction is generated, the SIP format instruction is sent to an SIP format instruction queue (command instruction), and the SIP format instruction is put into the SIP format instruction queue, so that the possibility that the SIP format instruction is not processed for a long time and is lost is avoided, and the stability of a session is improved. And each SIP format instruction is obtained from the SIP format instruction queue through an SIP protocol stack and is sent to the corresponding data acquisition equipment.

The flow of processing by the user mode session module, the service session module and the SIP session module in the whole process of sending the session request from the request end to the data acquisition device can be understood together with fig. 6.

In an embodiment, if the service session corresponding to the device identifier exists, step 107 is executed.

And 107, updating the service session corresponding to the equipment identification by using the service session thread according to the serialized request object.

And if the service session corresponding to the equipment identifier exists, the service session thread updates the service session corresponding to the equipment identifier according to the serialized request object. For example, the atomic sequence number and connection pool handle in the serialized request object are added to the request list of the service session to update the corresponding service session.

In the embodiment, the part of the data acquisition equipment and the request end related to session processing is divided into three different session modules, different session processing is performed through the different session modules, the modules have independent functions and extremely low coupling, and the coupling among the session modules is reduced; secondly, the communication between the modules is only to send the corresponding request object to the queue corresponding to the next module, the communication is simple, and the conversation processing and communication are carried out in a thread mode, so that the asynchronous communication between the modules is realized, and the stability of the whole conversation process and the safety of the conversation are ensured; in addition, when the service session is generated, one device identifier is generated according to the device identifiers, and when the device identifiers are the same, a plurality of request terminals can share one service session, so that the session efficiency is improved.

Fig. 7 is another flowchart of a session management method provided in an embodiment of the present application, where the session management method is applicable to a server, and the session management method includes the following steps.

201, generating a serialized response object corresponding to the SIP response message of the data acquisition device through the SIP protocol stack and the SIP session module, and sending the serialized response object to a serialized message queue of the service session module.

In an embodiment, the step of generating the serialized response object corresponding to the SIP response message of the data acquisition device through the SIP protocol stack and the SIP session module includes: receiving an SIP response message of the data acquisition equipment through an SIP protocol stack; performing second format conversion on the SIP response message to obtain an SIP response object corresponding to the SIP response message; sending the SIP response object to an SIP object pool; and the SIP session thread of the SIP session module acquires the SIP response object from the SIP object pool and carries out second serialization on the SIP response object to obtain a serialized response object.

The data acquisition equipment returns an SIP response message based on the SIP format instruction, the SIP response message comprises information such as an SIP session identifier, an atomic serial number (the atomic serial number is consistent with the atomic serial number in the SIP request object) and the like, and the SIP protocol stack receives the SIP response message returned by the data acquisition equipment. Because the protocol relied by the data acquisition equipment is GB/T28181, the SIP response message is a message conforming to GB/T28181, and therefore, the SIP response message needs to be converted into a popular and understandable SIP response object by a protocol stack after being converted into a second format conversion, so that the management is convenient, and the learning difficulty is reduced. And sending the SIP response object to the SIP object pool.

And the SIP session thread of the SIP session module acquires the SIP response object from the SIP object pool and carries out second serialization on the SIP response object to obtain the serialized response object, so that the SIP response object in the SIP format is converted into the serialized response object in the binary format, and the serialized response object is sent to the serialized message queue of the service session module.

202, the service session module determines a corresponding service session according to the SIP session identifier in the serialized response object, and returns the service address and the service port of the service session to the request end corresponding to the serialized request object information in the request list according to the serialized response object.

The serialized response object comprises information such as SIP session identification and atomic serial number.

The step of determining the corresponding service session by the service session module according to the SIP session identifier in the serialized response object includes: and the service session thread of the service session module acquires the serialized response object from the serialized message queue, acquires the SIP session identifier in the serialized response object, matches the SIP session identifier with the SIP session identifier in each service session in used of the service session group, and if the matching is successful, the service session is the corresponding service session.

At this point, the session state in the service session is updated, where the session state may be either successful or recognized, and whether successful or failed, the list of requests in the service session needs to be traversed. When the session state is successful, returning the media address, the service port (including an RTP port and a P2P port), and the like of the media server to the request end corresponding to each piece of serialized request object information in the request list; if the session state is failure (if there may be no data acquisition device corresponding to the device identifier or the data acquisition device is not online, etc.), the corresponding failure information is returned to the request end corresponding to each piece of serialized request object information in the request list.

The step of returning the service address and the service port of the service session to the request end corresponding to the serialized request object information in the request list according to the serialized response object includes: traversing the request list, and detecting whether the atomic sequence number in the serialized response object is consistent with the atomic sequence number in the request list; if the atomic sequence numbers are not consistent with the atomic sequence numbers, the serialized request object information corresponding to the atomic sequence numbers is deleted from the request list, and the serialized response object is discarded; and if the consistency exists, returning the media address and the service port of the service session to the request end corresponding to the serialized request object information according to the connection pool handle.

And if the atomic sequence numbers are not consistent, the fact that the request ends corresponding to the atomic sequence numbers are all disconnected means that the serialized request object information corresponding to the atomic serialization is deleted from the request list, and the serialized response object is discarded. If the atomic serial numbers are consistent, the response is normal, and the media address and the service port of the media server in the service session are returned to the request end corresponding to the connection pool handle according to the connection pool handle corresponding to the atomic serial numbers.

Because the connection pool handle points to the corresponding connection pool handle description information, the connection pool handle description information includes the network communication handle, and the media address and the service port of the body server can be returned to the requesting end through the network communication handle.

In an embodiment, after obtaining the media address and the service port, the request end registers with the service port (P2P port) of the media address of the media server, so that the media server sends the data of the data acquisition device acquired through the service port (RTP port) to the request end through the corresponding P2P port.

The SIP response message sent from the data acquisition device to the SIP protocol stack may also be understood as a SIP request sent from the data acquisition device, and it should be noted that the SIP request is a SIP response message and is returned by the data acquisition device based on the session request sent by the request end. In some embodiments, the data collection device may send a SIP request to the protocol stack, for example, a log-off command sent by the data collection device or a request terminal subscribed to the data collection device actively sends the state of the data collection device to the data collection device actively.

The processing flow of the SIP session module, the service session module and the user mode session module in the whole process of returning the SIP request from the data acquisition device to the request end can be understood together with fig. 8.

In the above embodiment, the session management method further includes: when the request list in the service session is detected to be empty, a session ending request (BYE request) is sent to the SIP session module through the service session thread, the session ending request is converted into a corresponding SIP request object and sent to the SIP object pool, the SIP session thread of the SIP session module acquires the SIP request object from the SIP object pool and converts the SIP request object into a corresponding SIP format instruction (ending instruction), the SIP format instruction (ending instruction) is sent to the SIP format instruction queue, and the SIP format instruction (ending instruction) is acquired from the SIP format instruction queue through the SIP protocol stack so as to end the SIP session with the data acquisition device. When the request end is disconnected or sends a video which is not watched, the corresponding atomic sequence number and the corresponding connection pool handle are deleted from the request list.

In the above embodiment, the session management method further includes: when detecting that the data acquisition device sends an SIP request (such as a BYE request), for example, the data acquisition device sends a logout instruction, the BYE request is sent, and since the data generation source does not exist at this time, the SIP request needs to be sent to the request end through the SIP session module, the service session module, and the user mode session module. Specifically, please refer to the above corresponding process, which is not described herein again.

Correspondingly, fig. 9 is a schematic structural diagram of a server provided in the embodiment of the present application; referring to fig. 9, the server includes: the system comprises a user state session module, a service session module and an SIP session module.

The user state conversation module comprises a user state message queue and a user state conversation thread pool group, wherein the user state conversation thread pool group comprises a plurality of user state conversation threads; and acquiring the session request from the user mode message queue according to a user mode session thread, generating a serialized request object corresponding to the session request according to the request identifier, and sending the serialized request object to a serialized message queue of the service session module.

The service session module comprises a serialized message queue, a service session thread pool group and a service session group, wherein the service session thread pool group comprises a plurality of service session threads, the service session group comprises a plurality of service sessions, and the service session module is used for acquiring the serialized request object from the serialized message queue by using the service session threads and detecting whether the service session corresponding to the device identifier exists or not according to the device identifier in the serialized request object; if the SIP request object does not exist, a service session corresponding to the equipment identifier is generated, an SIP request object corresponding to the equipment identifier is generated according to the service session, and the SIP request object is sent to an SIP object pool of an SIP session module.

And the SIP session module comprises an SIP object pool, an SIP format instruction queue, an SIP session thread pool group and the like, wherein the SIP session thread pool group comprises a plurality of SIP session threads, and the SIP session module is used for acquiring the SIP request object from the SIP object pool by using the SIP session threads and sending the SIP request object to the data acquisition equipment corresponding to the equipment identifier through an SIP protocol stack.

The functions specifically implemented by the user mode session module, the service session module, and the SIP session module may refer to the description in any embodiment of the session management method, and the beneficial effects achieved by the functions may also refer to the description of the corresponding parts in the foregoing description, which is not repeated herein.

Accordingly, embodiments of the present application also provide a server, as shown in fig. 10, the server may include Radio Frequency (RF) circuit 301, memory 302 including one or more computer-readable storage media, input unit 303, display unit 304, sensor 305, audio circuit 306, Wireless Fidelity (WiFi) module 307, processor 308 including one or more processing cores, and power supply 309. Those skilled in the art will appreciate that the server architecture shown in FIG. 10 is not meant to be limiting and may include more or fewer components than those shown, or some combination of parts, or a different arrangement of components. Wherein:

the RF circuit 301 may be used for receiving and transmitting signals during information transmission and reception or during a call, and in particular, for receiving downlink information from a base station and then processing the received downlink information by one or more processors 308; in addition, data relating to the shape of the preamble is transmitted to the base station. The memory 302 may be used to store software programs and modules, and the processor 308 executes various functional applications and data processing by operating the software programs and modules stored in the memory 302. The input unit 303 may be used to receive input numeric or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

The display unit 304 may be used to display information input by or provided to the user and various graphical user interfaces of the server, which may be made up of graphics, text, icons, video, and any combination thereof.

The server may also include at least one sensor 305, such as light sensors, motion sensors, and other sensors. Audio circuitry 306 includes speakers that may provide an audio interface between the user and the server.

WiFi belongs to short distance wireless transmission technology, and the server can help the user send and receive e-mail, browse web page and access streaming media, etc. through the WiFi module 307, which provides wireless broadband internet access for the user. Although fig. 10 shows the WiFi module 307, it is understood that it does not belong to the essential constitution of the server, and may be omitted entirely as needed within the scope of not changing the essence of the application.

The processor 308 is a control center of the server, connects various parts of the entire handset by using various interfaces and lines, performs various functions of the server and processes data by operating or executing software programs and/or modules stored in the memory 302 and calling data stored in the memory 302, thereby integrally monitoring the handset.

The server also includes a power supply 309 (e.g., a battery) for powering the various components, which may preferably be logically connected to the processor 308 via a power management system, such that the power management system may perform functions of managing charging, discharging, and power consumption.

Although not shown, the server may further include a camera, a bluetooth module, etc., which will not be described herein. Specifically, in this embodiment, the processor 308 in the server loads the executable file corresponding to the process of one or more application programs into the memory 302 according to the following instructions, and the processor 308 runs the application programs stored in the memory 302, thereby implementing the following functions:

receiving a session request from a request terminal through a user mode message queue of a user mode session module, wherein the session request is used for requesting a session with data acquisition equipment, and the session request comprises a request identifier of the request terminal and an equipment identifier of the data acquisition equipment; acquiring the session request from the user state message queue according to a user state session thread of a user state session module, generating a serialized request object corresponding to the session request according to the request identifier, and sending the serialized request object to a serialized message queue of a service session module; acquiring the serialized request object from the serialized message queue according to a service session thread of the service session module, and detecting whether a service session corresponding to the equipment identifier exists or not according to the equipment identifier in the serialized request object; if the SIP request object does not exist, generating a service session corresponding to the equipment identifier, generating an SIP request object corresponding to the equipment identifier according to the service session, and sending the SIP request object to an SIP object pool of an SIP session module; and acquiring the SIP request object from the SIP object pool according to the SIP session thread of the SIP session module, and sending the SIP request object to the data acquisition equipment corresponding to the equipment identifier through an SIP protocol stack.

In the above embodiments, the descriptions of the respective embodiments have respective emphasis, and parts that are not described in detail in a certain embodiment may refer to the above detailed description, and are not described herein again.

It will be understood by those skilled in the art that all or part of the steps of the methods of the above embodiments may be performed by instructions or by associated hardware controlled by the instructions, which may be stored in a computer readable storage medium and loaded and executed by a processor.

To this end, an embodiment of the present application provides a computer-readable storage medium, in which a plurality of instructions are stored, and the instructions can be loaded by a processor to implement the following functions:

receiving a session request from a request terminal through a user mode message queue of a user mode session module, wherein the session request is used for requesting a session with data acquisition equipment, and the session request comprises a request identifier of the request terminal and an equipment identifier of the data acquisition equipment; acquiring the session request from the user state message queue according to the user state session thread of the user state session module, generating a serialized request object corresponding to the session request according to the request identifier, and sending the serialized request object to a serialized message queue of a service session module; acquiring the serialized request object from the serialized message queue according to a service session thread of the service session module, and detecting whether a service session corresponding to the equipment identifier exists or not according to the equipment identifier in the serialized request object; if the SIP request object does not exist, generating a service session corresponding to the equipment identifier, generating an SIP request object corresponding to the equipment identifier according to the service session, and sending the SIP request object to an SIP object pool of an SIP session module; and acquiring the SIP request object from the SIP object pool according to the SIP session thread of the SIP session module, and sending the SIP request object to the data acquisition equipment corresponding to the equipment identifier through an SIP protocol stack.

The above operations can be implemented in the foregoing embodiments, and are not described in detail herein.

Wherein the storage medium may include: read Only Memory (ROM), Random Access Memory (RAM), magnetic or optical disks, and the like.

Since the instructions stored in the storage medium may perform the steps of any one of the methods provided in the embodiments of the present application, beneficial effects that can be achieved by any one of the methods provided in the embodiments of the present application may be achieved, for details, see the foregoing embodiments, and are not described herein again.

In the foregoing embodiments, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.

The above detailed description is given to a session management method and apparatus, a server, and a computer-readable storage medium provided in the embodiments of the present application, and a specific example is applied in the present application to explain the principle and the implementation of the present application, and the description of the above embodiments is only used to help understand the technical solution and the core idea of the present application; those of ordinary skill in the art will understand that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; such modifications or substitutions do not depart from the spirit and scope of the present disclosure as defined by the appended claims.

Claims

1. A session management method is applied to a server, wherein the server comprises a user mode session module, a service session module and an SIP session module, and the session management method comprises the following steps:

2. The session management method according to claim 1, wherein the step of generating the service session corresponding to the device identifier comprises:

determining an idle service session from the set of idle service sessions;

filling the equipment identifier and the request list in the service session according to the serialized request object, and updating the session state in the service session to obtain the service session corresponding to the equipment identifier;

adding the service session to a group of service sessions in use.

3. The session management method according to claim 1, wherein the service session includes a session state, and the step of generating the SIP request object corresponding to the device identifier according to the service session includes:

acquiring a session state of the service session;

and when the session state is a preset state, performing first format conversion on the serialized request object to generate an SIP request object corresponding to the equipment identifier.

4. The session management method according to claim 1, wherein the step of generating the serialized request object corresponding to the session request according to the request identifier comprises:

generating connection pool handle description information corresponding to the session request by using the user mode session thread according to the request identifier;

and performing first serialization on the session request according to the connection pool handle description information to obtain a serialization request object corresponding to the session request.

5. The session management method according to claim 1, wherein the step of sending the SIP request object to the data collection device corresponding to the device identifier through a SIP protocol stack includes:

after the SIP request object is obtained through the SIP session thread, the SIP request object is packaged into an SIP format instruction;

sending the SIP format instruction to an SIP format instruction queue;

and acquiring the SIP format instruction from the SIP format instruction queue through an SIP protocol stack, and sending the SIP format instruction to the data acquisition equipment corresponding to the equipment identifier.

6. The session management method according to claim 1, wherein the service session includes a SIP session identifier and a request list, the SIP session identifier is obtained by updating the service session after the SIP request object is sent to a SIP session module, and the session management method further includes:

generating a serialized response object corresponding to the SIP response message of the data acquisition equipment through the SIP protocol stack and the SIP session module;

and the service session module determines the corresponding service session according to the SIP session identifier in the serialized response object, and returns the service address and the service port of the service session to the request end corresponding to the serialized request object information in the request list according to the serialized response object.

7. The session management method according to claim 6, wherein the step of generating the serialized response object corresponding to the SIP response message of the data acquisition device through the SIP protocol stack and the SIP session module includes:

receiving an SIP response message of the data acquisition equipment through the SIP protocol stack;

performing second format conversion on the SIP response message to obtain an SIP response object corresponding to the SIP response message;

sending the SIP response object to an SIP object pool;

and the SIP session thread of the SIP session module acquires the SIP response object from the SIP object pool and carries out second serialization on the SIP response object so as to obtain a serialized response object.

8. The session management method according to claim 6, wherein the serialized reply object includes an atomic sequence number, and the serialized request object information in the request list includes an atomic sequence number and a connection pool handle; the step of returning the service address and the service port of the service session to the request end corresponding to the serialized request object information in the request list according to the serialized response object includes:

traversing a request list, and detecting whether the atomic sequence number in the serialized response object is consistent with the atomic sequence number in the request list;

if the request list is not consistent with the serialized request object information, deleting the corresponding serialized request object information from the request list, and discarding the serialized response object;

and if the connection pool handle is consistent with the serialized request object information, returning the media address and the service port in the service session to the request end corresponding to the serialized request object information according to the connection pool handle.

9. A server, characterized in that the server comprises a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor executes the program to implement the steps in the session management method according to any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that it stores a computer program which, when executed by a processor, implements the steps in the session management method according to any one of the preceding claims 1 to 8.