A Device Scheduling Method, Device, Equipment and Medium for an OLT Registration and Traffic Generation Workstation

Abstract

The present application provides a device scheduling method, device, equipment and medium for an OLT registration and traffic injection station, which relates to the technical field of device debugging and is used to solve the control problem of different types of external devices on the OLT registration and traffic injection station. This method is applied to a UDP server, which is connected to the client of the OLT registration and traffic injection station. The OLT registration and traffic injection station is integrated with multiple test devices, and the UDP server is integrated with interfaces of multiple test devices. The method includes: receiving a UDP message sent by the client; parsing the UDP message to obtain multiple parameters; the multiple parameters include the protocol type; determining a target test device from the multiple test devices according to the protocol type; calling the target test device to execute the corresponding operation, and sending an acknowledgment message to the client. By centrally controlling multiple external test devices of the OLT registration and traffic injection station through the UDP server, the control problem of different types of external devices is solved.

Description

Technical Field

[0001] The present application relates to the technical field of equipment debugging, and provides a method, device, equipment and medium for equipment scheduling at an OLT registration and traffic injection station. Background Art

[0002] Fiber To The Room (FTTR) is a new type of fiber broadband access technology. The optical network terminal (ONT) converts the external fiber optic signal into a signal that can be used by the home network, and the integrated gateway is responsible for distributing the network signal from the ONT to the terminal devices in each room.

[0003] During the production process of ONT products, the OLT registration and traffic injection station is the last process in production group testing. The purpose is to simulate the actual use of the ONT, connect the optical network terminal (ONT) and optical network unit (ONT) to the optical line terminal (OLT) and complete the authentication and configuration process to ensure the actual experience quality of users after the service is opened.

[0004] In order to optimize the production process flow and improve efficiency, the BOB test and voice test can be combined into the OLT registration and traffic injection station. However, the BOB devices required for the BOB test and the voice card devices required for the voice test may come from multiple different manufacturers, and the communication methods of each manufacturer are different, and the application programming interfaces (APIs) developed are also different. Moreover, the production test program provided by the traffic injection station manufacturer cannot develop control interfaces for third-party external devices. Therefore, how to solve the control problems of different types of devices is an urgent problem to be solved. Summary of the Invention

[0005] The present application provides a method, device, equipment and medium for equipment scheduling at an OLT registration and traffic injection station, which is used to solve the control problems of different types of external devices at the OLT registration and traffic injection station.

[0006] In a first aspect, a method for equipment scheduling at an OLT registration and traffic injection station is provided, which is applied to a UDP server. The UDP server is connected to a client at the OLT registration and traffic injection station. The OLT registration and traffic injection station is integrated with multiple test devices, and the UDP server is integrated with interfaces of the multiple test devices. The method includes:

[0007] Receiving a UDP message sent by the client;

[0008] Parsing the UDP message to obtain multiple parameters; the multiple parameters include a protocol type;

[0009] Determine a target test device from the multiple test devices according to the protocol type;

[0010] Invoke the target test device to perform corresponding operations and send a confirmation message to the client.

[0011] Optionally, before receiving the UDP message sent by the client, the method further includes:

[0012] Create multiple worker threads;

[0013] Create a local endpoint using the IPEndPoint class and bind the local endpoint to all available network interfaces and a specified port;

[0014] Create a UDP socket using the Socket class, bind the UDP socket to the local endpoint, and wait to receive UDP messages.

[0015] Optionally, the multiple parameters further include a channel identifier; the determining a target test device from the multiple test devices according to the protocol type includes:

[0016] Obtain a thread identifier according to the channel identifier;

[0017] If the thread identifier does not exceed the identifier range of the multiple worker threads, determine a target thread from the multiple worker threads according to the thread identifier, and allocate the multiple parameters to the target thread;

[0018] Start the target thread and determine a target test device from the multiple test devices according to the protocol type.

[0019] Optionally, after obtaining the thread identifier according to the channel identifier, the method further includes:

[0020] If the thread identifier exceeds the identifier range of the multiple worker threads, return an exception message to the client.

[0021] Optionally, before starting the target thread and determining a target test device from the multiple test devices according to the protocol type, the method further includes:

[0022] Store the multiple parameters and the endpoint information of the client into the commands array corresponding to the target thread;

[0023] Protect access to the commands array through a mutex.

[0024] Optionally, the multiple test devices include a BOB device and a voice card device; the BOB device includes a power meter, an attenuator, and an optical switch; determining a target test device from the multiple test devices according to the protocol type includes:

[0025] If the protocol type is BOB SET TXWL or GETPOWER, determine the power meter as the target test device;

[0026] If the protocol type is BOB SET RXWL or SETATT, determine the attenuator as the target test device;

[0027] If the protocol type is SWITCH, determine the optical switch as the target test device;

[0028] If the protocol type is RING, determine the voice card device as the target test device.

[0029] Optionally, the multiple parameters further include a test value; calling the target test device to perform a corresponding operation and sending a confirmation message to the client includes:

[0030] Determine a target operation according to the protocol type;

[0031] Call the target test device to perform the target operation according to the test value and send a confirmation message to the client.

[0032] In a second aspect, there is provided a device scheduling device for an OLT registration and traffic injection station, which is arranged in a UDP server. The UDP server is connected to a client of the OLT registration and traffic injection station. The OLT registration and traffic injection station is integrated with multiple test devices, and the UDP server is integrated with interfaces of the multiple test devices; the device includes:

[0033] A receiving module, configured to receive a UDP message sent by the client;

[0034] A parsing module, configured to parse the UDP message to obtain multiple parameters; the multiple parameters include a protocol type for indicating a command type;

[0035] A determining module, configured to determine a target test device from the multiple test devices according to the protocol type;

[0036] An operation module, configured to call the target test device to perform a corresponding operation and send a confirmation message to the client.

[0037] In a third aspect, the present application provides a computer device, which includes a memory and a processor. A computer program is stored in the memory, and the processor executes the computer program to implement the device scheduling method for the OLT registration and traffic injection station in the first aspect.

[0038] In a fourth aspect, the present application provides a computer-readable storage medium, on which a computer program is stored. The processor executes the computer program to implement the device scheduling method for the OLT registration and traffic injection station in the first aspect.

[0039] Compared with the prior art, the beneficial effects of the present application are as follows:

[0040] The present application provides a device scheduling method for an OLT registration and traffic injection station. The method is applied to a UDP server, which is connected to the client of the OLT registration and traffic injection station. The OLT registration and traffic injection station integrates multiple test devices, and the UDP server integrates interfaces for multiple test devices. The method includes: receiving a UDP message sent by the client; parsing the UDP message to obtain multiple parameters; the multiple parameters include the protocol type; determining a target test device from the multiple test devices according to the protocol type; calling the target test device to execute the corresponding operation, and sending an acknowledgment message to the client.

[0041] In the present application, by centrally controlling multiple externally connected third-party test devices of the OLT registration and traffic injection station through the UDP server, the control problem of different types of externally connected devices on the OLT registration and traffic injection station is solved. Thus, the merging of multiple test items can be achieved on the OLT registration and traffic injection station, which can effectively improve the test coverage, automation level, reduce manual intervention, and ultimately improve the overall test quality and production efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following will briefly introduce the drawings required for use in the description of the embodiments or related technologies. Obviously, the drawings in the following description are only the embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained according to the provided drawings without creative efforts.

[0043] Figure 1 It is a schematic diagram of the application scenario provided by the embodiment of the present application;

[0044] Figure 2 It is a schematic flowchart of the device scheduling method for the OLT registration and traffic injection station provided by the embodiment of the present application;

[0045] Figure 3 It is a schematic diagram of the client configuration interface for setting attenuation provided by the embodiment of the present application;

[0046] Figure 4 Schematic diagram of the client configuration interface for obtaining power provided by the embodiments of the present application;

[0047] Figure 5 Schematic diagram of the client configuration interface for setting the optical switch provided by the embodiments of the present application;

[0048] Figure 6 Schematic diagram of the structure of the device scheduling device for the OLT registration and traffic injection station provided by the embodiments of the present application. Detailed implementation manners

[0049] To make the objectives, technical solutions and advantages of the present application clearer and more understandable, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without making creative efforts belong to the scope of protection of the present application. Without conflict, the embodiments in the present application and the features in the embodiments can be arbitrarily combined with each other. And although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0050] Since the secondary development interfaces provided by equipment suppliers can only communicate through the UPD / TCP method, however, BOB devices (including optical power meters and attenuators) all adopt the communication control method of CH341, and the voice card devices adopt the control method of the external Tc08a32.dll provided by the voice card device supplier. When combining BOB testing and voice testing into the OLT registration and traffic injection station, there are control problems for different types of external devices.

[0051] To solve the control problems of different types of external devices on the OLT registration and traffic injection station, the embodiments of the present application provide a device scheduling method for the OLT registration and traffic injection station, which is applied to a UDP server. Please refer to Figure 1 , which is a schematic diagram of an application scenario provided by the embodiments of the present application, or can be understood as a schematic diagram of the structure of the OLT registration and traffic injection station.

[0052] The OLT registration and traffic injection station includes a UDP server, a client, and multiple testing devices. The UDP server is a server program developed by users, running in the background of the OLT registration and traffic injection station, and integrating the interfaces of multiple testing devices. The client is the interface program of the OLT registration and traffic injection station, and establishes a connection with the UDP server through the interface protocol.

[0053] Multiple test devices include BOB devices and voice card devices. Among them, the BOB device is used for BOB testing of BOB products (such as optical modems), to detect whether the optical power emitted by the BOB product is within the required range, and whether the optical power received by the BOB product is consistent with the actually monitored optical power. The voice card device is used to simulate functions such as the ringing, off-hook, dialing, and hanging up of a telephone.

[0054] The BOB device includes a power meter, an attenuator, and an optical switch. The BOB product is an optical transceiver integrated product, and the optical power emitted by the BOB product needs to be monitored. Therefore, the power meter is located at the transmitting end of the BOB product, mainly used to detect and adjust the power of the optical signal transmitted by the BOB product to ensure that the signal meets the requirements. The light received by the BOB product is attenuated light. Therefore, the attenuator is located at the receiving end of the BOB product, used to adjust the intensity of the optical signal. Especially when the signal is too strong, the attenuator is used to reduce the intensity of the optical signal to avoid overloading or the receiving end being unable to process the overly strong signal. The optical switch is located between the transmitting end and the receiving end, used to switch signals between multiple optical paths and control the flow direction of the optical signal to different directions.

[0055] It should be noted that Figure 1 taking multiple test devices including BOD devices (power meter, attenuator, optical switch) and voice test devices as an example, actually the types and quantities of test devices are not restricted. Users can configure these multiple test devices in the UDP server according to the devices actually used in production.

[0056] In order to integrate the interfaces of multiple test devices in the UDP server and be able to select different types of test devices through configuration, communication interface protocols are formulated for different test devices. The following introduces various interface protocols respectively.

[0057] 1. Protocol for setting the transmitting wavelength of the device: "BOB SET TXWL X1 X2".

[0058] Among them, BOB SET TXWL is the protocol type. X1 is the channel identifier. The device has 8 channels, and the value range of X1 is a positive integer from 1 to 8. X2 is the test value, representing the specific wavelength to be set, which can be 1310nm or 1277nm.

[0059] 2. Protocol for setting the receiving wavelength of the device: "BOB SET RXWL X1 X2".

[0060] Among them, BOB SET RXWL is the protocol type, X1 is the channel identifier. The device has 8 channels, and the value range of X1 is a positive integer from 1 to 8. X2 is the test value, representing the specific wavelength to be set, which can be 1490nm or 1550nm.

[0061] 3. Protocol for obtaining the optical power at the transmitting end: "GETPOWER X1"

[0062] Among them, GETPOWER is the protocol type, and X1 is the channel identifier. The device has 8 channels, and the value range of X1 is a positive integer from 1 to 8.

[0063] 4. Protocol for setting the optical attenuation at the receiving end: "SETATT X1 X2".

[0064] Among them, SETATT is the protocol type, X1 is the channel identifier. The device has 8 channels, and the value range of X1 is a positive integer from 1 to 8. X2 is the test value, representing the set attenuation value.

[0065] 5. Protocol for setting the optical switch to switch: "SWITCH X1 X2".

[0066] Among them, SWITCH is the protocol type, X1 is the channel identifier. The device has 8 channels, and the value range of X1 is a positive integer from 1 to 8. X2 is the test value, and the value of X2 is 1 or 2, indicating that each channel has two optical paths. X2 = 1 represents setting to the first optical path, and X2 = 2 represents setting to the second optical path.

[0067] 6. Protocol for setting the voice test: "RING X1".

[0068] Among them, RING is the protocol type, X1 is the channel identifier. The device has 8 channels, and the value range of X1 is a positive integer from 1 to 8.

[0069] As can be seen from the above various protocols, the protocol for obtaining the optical power at the transmitting end and the protocol for setting the voice test do not contain test values.

[0070] Based on Figure 1 the application scenario shown, the following introduces Figure 2 a device scheduling method for an OLT registration and traffic injection workstation shown.

[0071] S201. Receive the UDP message sent by the client.

[0072] In the specific implementation process, the UDP server can use the uServer.ReceiveFrom method to receive the UDP message sent by the client (any one of the 6 interface protocols introduced above) and store the UDP message in the receive buffer (ReceiveBuffer).

[0073] Before executing S201, it is first necessary to create a UDP server in the background of the OLT registration and traffic injection workstation. The specific steps are as follows:

[0074] Create multiple worker threads; use the IPEndPoint class to create a local endpoint, bind the local endpoint to all available network interfaces and the specified port; use the Socket class to create a UDP socket, bind the UDP socket to the local endpoint, and wait to receive UDP messages.

[0075] In the specific implementation process, first, multiple worker threads can be created through a for loop. Each worker thread executes the WorkerThread method and passes an index as a parameter. The commands array is used to store the command information of each worker thread. Second, a UDP socket can be created using the Socket class, specifying the address family, socket type, and command type. Then, a local endpoint can be created using the IPEndPoint class and bound to all available network interfaces and the specified port. Next, the UDP socket can be bound to the local endpoint so that UDP messages can be received.

[0076] Considering that both the BOB device and the voice card device are multi-channel devices, multiple channels can be tested in parallel. Therefore, in the embodiment of the present application, by creating multiple worker threads, multiple worker threads can simultaneously process multiple UDP messages (interface protocols) in parallel. Different threads can be responsible for the test tasks of different channels, realizing multi-channel parallel testing of the OLT group test streaming station and improving the overall test efficiency.

[0077] S202. Parse the UDP message to obtain multiple parameters.

[0078] After receiving the UDP message, the UDP server can convert the received byte array into a string and parse it to obtain multiple parameters. The multiple parameters include the protocol type, channel identifier, and test value. The channel identifier is used to uniquely identify each channel, and the test value is used to indicate the specific parameter value that needs to be set for the test, such as wavelength, attenuation value, etc. The protocol types include the protocol for setting the transmitting wavelength of the device, the protocol for setting the receiving wavelength of the device, the protocol for obtaining the transmitting optical power, the protocol for setting the receiving optical attenuation, the protocol for setting the optical switch switching, and the protocol for setting the voice test.

[0079] It should be noted that there is no test value for the protocol of obtaining the transmitting optical power of each channel and the protocol of setting the voice test.

[0080] S203. Determine the target test device from multiple test devices according to the protocol type.

[0081] In a possible embodiment, the specific steps of S203 include:

[0082] Obtain a thread identifier according to the channel identifier; if the thread identifier does not exceed the identifier range of multiple worker threads, determine the target thread from the multiple worker threads according to the thread identifier, and allocate multiple parameters to the target thread; start the target thread, and determine the target test device from multiple test devices according to the protocol type.

[0083] In the specific implementation process, after the UDP server obtains the channel identifier, it can query the mapping table. The mapping table includes multiple channel identifiers and the thread identifier corresponding to each channel identifier. According to the channel identifier, the corresponding thread identifier is determined. Alternatively, a hash operation can be performed on the channel identifier, and the obtained hash value is the thread identifier. Then, it can be confirmed whether the thread identifier is within the valid identifier range. Assume that the identifier range of the worker threads is from 1 to MaxCount (for example, the maximum is 10). If the calculated thread identifier is less than MaxCount, multiple parameters are allocated to the target thread, and the target thread can use these parameters to execute specific tasks. Finally, start the target thread to execute the task. When the target thread executes, it can determine the target test device to be used according to the protocol type.

[0084] In the embodiment of the present application, tasks can be flexibly allocated to the corresponding worker threads according to the thread identifier. Different tasks can be processed in parallel, avoiding blocking between threads. Each worker thread runs independently. In case a certain worker thread encounters an error (for example, a certain device cannot be started), it will not affect the execution of other threads, and it is easier for the system to locate which thread has a problem, thus making it easier to debug and repair. And this structure is very suitable for expansion. If more test devices need to be supported in the future, only more thread pools need to be added, and there is no need to reconstruct the entire system.

[0085] In a possible embodiment, after obtaining the thread identifier according to the channel identifier, the method further includes:

[0086] If the thread identifier exceeds the identifier range of multiple worker threads, an exception message is returned to the client.

[0087] In the embodiment of the present application, by checking for invalid thread IDs, the system can be prevented from performing incorrect operations, avoiding the program from continuing to execute when encountering invalid input, and reducing the possibility of system failures. And once the client provides invalid input, it can receive feedback in a timely manner, avoiding meaningless processing in subsequent steps, saving time and computing resources.

[0088] In a possible embodiment, before starting the target thread and determining the target test device from multiple test devices according to the protocol type, the method further includes:

[0089] Store multiple parameters and the endpoint information of the client into the commands array corresponding to the target thread;

[0090] Access to the commands array is protected by a mutex.

[0091] In a specific implementation process, before starting the target thread, multiple parameters and the endpoint information of the client are stored in the commands array associated with the target thread. The endpoint information of the client usually refers to the relevant information of the client network interface for identification and communication, including the IP address, port number, etc. Each worker thread has its own commands array to store its relevant command information (i.e., multiple parameters). Access to the commands array is protected by a mutex to ensure that only the target thread can modify or access the commands array, which can avoid race conditions and ensure data consistency and thread safety.

[0092] In a possible embodiment, the step of determining the target test device from multiple test devices according to the protocol type includes:

[0093] If the protocol type is BOB SET TXWL or GETPOWER, the power meter is determined as the target test device; if the protocol type is BOB SET RXWL or SETATT, the attenuator is determined as the target test device; if the protocol type is SWITCH, the optical switch is determined as the target test device; if the protocol type is RING, the voice card device is determined as the target test device.

[0094] In the embodiments of the present application, through simple conditional judgments, the target test device can be screened out from multiple test devices according to different protocol types to ensure that each protocol type cooperates with a suitable test device.

[0095] S204. Invoke the target test device to perform the corresponding operation and send a confirmation message to the client.

[0096] In a specific implementation process, if the multiple parameters do not include the test value, the target operation can be determined according to the protocol type, and the target test device can be directly invoked to perform the target operation and send a confirmation message to the client. If the multiple parameters do not include the test value, the target operation is determined according to the protocol type; the target test device is invoked to perform the target operation according to the test value and send a confirmation message to the client. The confirmation message can indicate whether the execution of the target operation is successful or failed, and can also include specific device return values, such as the optical power value.

[0097] Since the light received by the power meter is the light emitted by the BOB product, it is necessary to set the power meter to the same wavelength as the transmitting end of the BOB product. For example, if the protocol sent by the client is BOB SET TXWL 1 1310, the target thread can determine that the target operation is to set the transmitting-end wavelength according to the protocol type BOB SET TXWL, then set the wavelength of channel 1 of the power meter to 1310 nm, and send an acknowledgment message to the client.

[0098] Since the light received by the BOB product is the light transmitted by the attenuator, it is necessary to set the attenuator to the same wavelength as the receiving end of the BOB product. For example, if the protocol sent by the client is BOB SET RXWL 1 1490, the target thread can determine that the target operation is to set the receiving-end wavelength according to the protocol type BOB SET RXWL, then set the wavelength of channel 1 of the attenuator to 1490 nm, and send an acknowledgment message to the client.

[0099] For example, if the protocol sent by the client is GETPOWER 1, the target thread can determine that the target operation is to obtain the optical power according to the protocol type GETPOWER, then call the power meter to obtain the power value of channel 1. Each channel corresponds to an actual line loss value. Add the line loss value of channel 1 to the power value obtained by the power meter to obtain the actual power value, and send an acknowledgment message to the client. The acknowledgment message can also include the actual power value.

[0100] For example, if the protocol sent by the client is SWITCH 1 2, the target thread can determine that the target operation is to switch the switch according to the protocol type SWITCH, then call the optical switch function to perform a switch operation on the optical switch device, switch channel 1 of the optical switch device to channel 2, and send an acknowledgment message to the client.

[0101] For example, if the protocol sent by the client is SETATT 1 10, the target thread can determine that the target operation is to set the attenuation according to the protocol type SETATT, then set the attenuation of channel 1 of the attenuator by 10 units of power, and send an acknowledgment message to the client.

[0102] For example, if the protocol sent by the client is RING 1, the target thread can determine that the target operation is a voice test according to the protocol type RING, then call channel 1 of the voice card device to perform voice tests such as voice ringing, off-hook / on-hook, and dialing, and send an acknowledgment message to the client. The acknowledgment message can also include the voice test results.

[0103] In summary, in the face of different types of test equipment, the present application provides a device method for the OLT registration and traffic injection station, developing an external UDP server program, i.e., a UDP server, and configuring the interface protocols of each test equipment in the UDP server, so as to integrate the interfaces of different types of test equipment such as BOD equipment and voice card equipment into the UDP server. Through the UDP communication method, the software of the OLT traffic injection station communicates with multiple test equipment (BOD equipment and voice card equipment), so as to realize the function combination of BOB test and voice test and improve the test and production efficiency.

[0104] After the UDP server is started, it will keep running in the background, continuously receive UDP messages sent by the client, and call the corresponding test equipment for operation, and send the return value of the test equipment to the client. The client can set the corresponding test equipment and obtain the return value of the test equipment by sending UDP messages (i.e., interface protocols) to the UDP server. The client configuration interface for setting attenuation is as Figure 3 shown, and the client configuration interface for obtaining power is as Figure 4 shown, and the client configuration interface for setting the optical switch is as Figure 5 shown.

[0105] Based on the same inventive concept, the present application also provides a device scheduling device for the OLT registration and traffic injection station, as Figure 6 shown. This device is set in the UDP server. The UDP server is connected to the client of the OLT registration and traffic injection station. The OLT registration and traffic injection station integrates multiple test equipment, and the UDP server integrates the interfaces of multiple test equipment. This device includes:

[0106] A receiving module, used to receive UDP messages sent by the client;

[0107] A parsing module, used to parse the UDP message to obtain multiple parameters; the multiple parameters include the protocol type used to indicate the command type;

[0108] A determination module, used to determine the target test equipment from multiple test equipment according to the protocol type;

[0109] An operation module, used to call the target test equipment to execute the corresponding operation and send a confirmation message to the client.

[0110] It should be noted that each module in the device scheduling device of the OLT registration and traffic injection station in this embodiment corresponds to each step in the device scheduling method of the OLT registration and traffic injection station in the foregoing embodiment. Therefore, the specific implementation manner of this embodiment can refer to the implementation manner of the foregoing device scheduling method of the OLT registration and traffic injection station, and will not be elaborated here.

[0111] In addition, in one embodiment, the present application further provides a computer device, which includes a processor, a memory, and a computer program stored in the memory. When the computer program is run by the processor, it implements the aforementioned device scheduling method for the OLT registration and traffic injection station.

[0112] In addition, in one embodiment, the present application further provides a computer storage medium, on which a computer program is stored. When the computer program is run by the processor, it implements the aforementioned device scheduling method for the OLT registration and traffic injection station.

[0113] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disc, or CD-ROM; or it may be various devices including one or any combination of the above memories. The computer may be various computing devices including smart terminals and servers.

[0114] In some embodiments, the executable instructions may be in the form of a program, software, software module, script, or code, and may be written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including being deployed as an independent program or being deployed as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0115] As an example, the executable instructions may or may not correspond to files in the file system, and may be stored as part of a file that stores other programs or data. For example, they may be stored in one or more scripts in a Hyper Text Markup Language (HTML) document, stored in a single file dedicated to the program being discussed, or stored in multiple cooperating files (such as files that store one or more modules, subroutines, or code portions).

[0116] As an example, the executable instructions may be deployed to be executed on one computing device, or on multiple computing devices located at one location, or on multiple computing devices distributed at multiple locations and interconnected by a communication network.

[0117] It should be noted that in this text, the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, such that a process, method, article or system comprising a series of elements not only includes those elements but also includes other elements not expressly listed, or elements inherent to such process, method, article or system. Without further limitation, an element defined by the phrase "comprising a..." does not exclude the presence of additional identical elements in the process, method, article or system comprising such element.

[0118] The serial numbers of the embodiments of the present application above are only for description and do not represent the superiority or inferiority of the embodiments.

[0119] Through the description of the above embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus a necessary general hardware platform. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation. Based on such an understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art can be embodied in the form of a software product. The computer software product is stored in a storage medium (such as a read-only memory / random access memory, magnetic disk, optical disk) and includes several instructions to enable a multimedia terminal device to execute the methods described in the various embodiments of the present application.

[0120] The above are only the preferred embodiments of the present application and do not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made by using the specification and drawings of the present application, or directly or indirectly applied in other related technical fields, shall be equally included in the patent protection scope of the present application.

Claims

1. A method for dispatching equipment for an OLT registration and streaming station, characterized in that: Applied to a UDP server, the UDP server is connected to a client of an OLT registration and streaming station, the OLT registration and streaming station is integrated with a plurality of test devices, and the UDP server is integrated with interfaces of the plurality of test devices; the method comprises: Receive a UDP message sent by the client; The UDP message is parsed to obtain multiple parameters; the multiple parameters include a protocol type and a channel identifier; the test device includes multiple channels; the channel identifier is used to uniquely identify one of the multiple channels; Determining a target test device from the plurality of test devices according to the protocol type; Calling the target test device to perform corresponding operations, and sending a confirmation message to the client; Before receiving the UDP message sent by the client, the method further includes: creating multiple working threads; using the IPEndPoint class to create a local endpoint, binding the local endpoint to all available network interfaces and designated ports; using the Socket class to create a UDP socket, binding the UDP socket to the local endpoint, and waiting to receive a UDP message; The method of determining a target test device from the multiple test devices according to the protocol type includes: obtaining a thread identifier according to the channel identifier; if the thread identifier does not exceed the identifier range of the multiple working threads, determining a target thread from the multiple working threads according to the thread identifier and assigning the multiple parameters to the target thread; starting the target thread, and determining a target test device from the multiple test devices according to the protocol type.

2. The device scheduling method for OLT registration and streaming station according to claim 1, characterized in that: After obtaining the thread identifier according to the channel identifier, the method further includes: If the thread identifier exceeds the identifier range of the multiple working threads, an exception message is returned to the client.

3. The device scheduling method for OLT registration and streaming station according to claim 1, characterized in that: Before starting the target thread and determining a target test device from the plurality of test devices according to the protocol type, the method further includes: Storing the multiple parameters and the endpoint information of the client into the commands array corresponding to the target thread; Access to the commands array is protected by a mutex lock.

4. The device scheduling method for OLT registration and streaming station according to claim 1, characterized in that: The multiple test devices include BOB devices and voice card devices; the BOB devices include a power meter, an attenuator, and an optical switch; and determining a target test device from the multiple test devices according to the protocol type includes: If the protocol type is BOB SET TXWL or GETPOWER, the power meter is determined as a target test device; If the protocol type is BOB SET RXWL or SETATT, determining the attenuator as a target test device; If the protocol type is SWITCH, determining the optical switch as a target test device; If the protocol type is RING, the voice card device is determined as the target test device.

5. The device scheduling method for OLT registration and streaming station according to claim 1, characterized in that: The multiple parameters also include test values; calling the target test device to perform a corresponding operation and sending a confirmation message to the client includes: Determining a target operation according to the protocol type; The target test device is called to perform the target operation according to the test value, and a confirmation message is sent to the client.

6. An equipment scheduling device for an OLT registration and streaming station, characterized in that: The UDP server is set in a UDP server, the UDP server is connected to the client of the OLT registration and streaming station, the OLT registration and streaming station is integrated with a plurality of test devices, and the UDP server is integrated with interfaces of the plurality of test devices; the device comprises: A receiving module, used for receiving a UDP message sent by the client; A parsing module, used to parse the UDP message to obtain multiple parameters; the multiple parameters include a protocol type and a channel identifier for indicating a command type; the test device includes multiple channels; the channel identifier is used to uniquely identify one of the multiple channels; A determination module, configured to determine a target test device from the plurality of test devices according to the protocol type; An operation module, used to call the target test device to perform a corresponding operation and send a confirmation message to the client; Before receiving the UDP message sent by the client, the method further includes: creating multiple working threads; using the IPEndPoint class to create a local endpoint, binding the local endpoint to all available network interfaces and designated ports; using the Socket class to create a UDP socket, binding the UDP socket to the local endpoint, and waiting to receive UDP messages; The method of determining a target test device from the multiple test devices according to the protocol type includes: obtaining a thread identifier according to the channel identifier; if the thread identifier does not exceed the identifier range of the multiple working threads, determining a target thread from the multiple working threads according to the thread identifier and assigning the multiple parameters to the target thread; starting the target thread, and determining a target test device from the multiple test devices according to the protocol type.

7. A computer device, characterized in that: The computer device comprises a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the device scheduling method for OLT registration and punching station according to any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and the processor executes the computer program to implement the device scheduling method for OLT registration and streaming stations according to any one of claims 1 to 5.

Images