Method for using multithreaded frame in online charging network service

Abstract

The invention provides a method for using multithreaded frame in online charging network service. The method comprises the following steps: network service process starts the listening socket of the server-side to listen so as to wait the client-side to connect, when the listening socket listens the connection of a new client-side, the network service process of the server-side derives a forward thread and a reverse thread, the forward thread reads forward data from the socket, and the reverse thread sends the data to the socket. The method of the invention can be used to ensure that the forward and reverse data of the network interface can be timely treated at any time, thus completely reducing the time delay of data at the network interface.

Description

technical field [0001] The invention relates to the field of online charging network services, in particular to a method for using a multi-thread framework for online charging network services. Background technique [0002] Online billing, that is, real-time billing, as a supplement to traditional offline billing, has been paid more and more attention by operators because of the characteristics of real-time billing, control of user arrears, and improvement of user perception. The online charging system (OCS system) adopts the Diameter CC protocol (dcc protocol) interface to connect with the core network elements, accepts the charging requests of the core network elements, and returns the results to the core network after the approval and authorization of the system to achieve control The purpose of the user's business. Throughout the process, the performance and stability of the interface between the OCS system and the core network is particularly important. The performance...

AI Technical Summary

Problems solved by technology

That is, read a piece of data from the forward socket, decode it and put it into the request queue inside the OCS system, and then read a piece of data from the return queue inside the OCS system and then send it to SCP after being encoded in the dcc format. Not every poll will have data, resulting in a lot of empty waiting

Or sometimes when a large amount of data suddenly appears on one side (such as the network side), because the program needs to take into account the timeliness of response message processing, half of the time is often wasted on processing the reverse message channel with a much smaller amount of data, resulting in The throughput rate of the system is very low. When the number of online users reaches more than 100w, it becomes the bottleneck module of the entire system. When it is busy, it often causes messages to block the channel.

In addition, the layering of the dcc protocol of the previous network service was unscientific, resulting in the new business being added and the whole-body changes being triggered, which was error-prone

Images