CN108959527B

CN108959527B - Method for reading and displaying interlocking log based on Windows file mapping technology

Info

Publication number: CN108959527B
Application number: CN201810691686.1A
Authority: CN
Inventors: 余日可; 马雯; 马锐; 韦启盟; 杨平; 陈小猛; 李新新; 宁丽敏
Original assignee: Casco Signal Ltd
Current assignee: Casco Signal Ltd
Priority date: 2018-06-28
Filing date: 2018-06-28
Publication date: 2023-06-09
Anticipated expiration: 2038-06-28
Also published as: CN108959527A

Abstract

The invention relates to a method for reading and displaying an interlocking log based on Windows file mapping technology, which comprises the following steps: step 1, a function of reading the deletion log is specially called for a single thread ReadLogThread to execute; step 2, the ReadLogThread waits for a semaphore trigger function executing function in a waitformultiple objects mode; step 3, when a semaphore triggers a WaitForMultipleObjects internal signal, firstly calling an InitOneMonthFMap to initialize a pointer for Windows file mapping; step 4, calling SearchbyTypeKeyWord to browse all related log files in sequence after the InitOneMonthFMap is completed, analyzing the content of the SearchbyTypeKeyWord, and recording the address information of the log entries meeting the requirements as a single log file recordonly; and 5, calculating the number nRecordCount of log strips to be displayed according to the size of the recordoly. Dat file and the recorded data quantity, and setting the number of the entries of the virtual list to be displayed as nRecordCount and the like. Compared with the prior art, the invention has the advantages of high efficiency, memory space saving and the like.

Description

Method for reading and displaying interlocking log based on Windows file mapping technology

Technical Field

The invention relates to the technical field of Windows file mapping, in particular to a method for reading and displaying an interlocking log based on a Windows file mapping technology.

Background

Various information during the operation of the interlock system needs to be recorded for the maintenance and playback of the interlock system. Thereby forming a large number of interlocking logs. In order to retrieve the interlock log when needed, the interlock maintenance platform has the function of log inquiry.

The interlock logging and viewing function is of great significance in interlock systems. The interlocking system is divided into an interlocking lower computer, an interlocking operation machine and an interlocking maintenance platform. The interlocking lower computer is responsible for running ground equipment, the interlocking operator is responsible for sending operating commands, and viewing the yard representation. The daily maintenance of the equipment is the basic function of the interlocking maintenance platform. The interlocking maintenance platform is used for daily maintenance of the interlocking equipment and is realized through recording and displaying an interlocking log. When the interlocking system fails, an interlocking maintainer checks the log recorded by the history of the interlocking maintenance desk calendar and can accurately position the failure point by combining the related conditions, thereby laying a foundation for timely maintenance.

The interlock logging and viewing function is of great significance in interlock systems. The interlocking lower computer only has an operation function and has no display function. The interlocking operation machine has a display function and a function of recording certain history data, but the content that can be recorded is limited. In order to be able to retrieve the required interlock logs in time when required, the interlock maintenance station needs to record the operation of the interlock with little effort. With the development of an interlocking system, the logs recorded by the interlocking maintenance platform are more and more detailed, and the log quantity is more and more large. Under the background, the original method for reading the interlocking log based on the IO stream is lower and lower in function, the reading speed is lower, and log contents are required to be loaded in a memory for timely display after reading, so that a larger load is also generated on a program memory. Such designs are not scientific and cannot accommodate the ever-evolving industry demands.

Disclosure of Invention

The invention aims to overcome the defects of the prior art and provide a method for reading and displaying an interlocking log based on Windows file mapping technology.

The aim of the invention can be achieved by the following technical scheme:

a method for reading and displaying an interlocking log based on a Windows file mapping technology, comprising the following steps:

step 1, a function of reading a screening log is specially called for a single thread ReadLogThread to execute;

step 2, the ReadLogThread waits for a semaphore trigger function executing function in a waitformultiple objects mode;

step 3, when a semaphore triggers a WaitForMultipleObjects internal signal, firstly calling an InitOneMonthFMap to initialize a pointer for Windows file mapping;

step 4, after the InitOneMonthFMap is completed, calling SearchbyTypeKeyWord to search all related log files in sequence according to the search condition, analyzing the content of the log files, and recording the address information of the log entries meeting the requirements as a single index file recordonly.

Step 5, according to the size of the index file recordoly. Dat, the recorded data volume calculates the number of journal entries to be displayed, nRecordCount, and sets the number of journal entries in the virtual list display area in the display interface as nRecordCount;

step 6, calling GetRECORDCTORC content to acquire the log content which should be displayed in the row when the virtual list is displayed inside;

and 7, in GetRescordContent, rapidly calculating according to the line number to obtain an address value in the log text in the corresponding log entry content recorded in the recordonnly. Dat, and directly reading the log in the log text according to the read address value, so as to display the log on an interface.

Preferably, the step 3 of initializing the pointer for mapping the Windows file specifically includes the following steps:

step 3.1, checking whether members in the file pointer group m_mapfile H_Month are used, if so, closing the file, releasing the memory, and setting the corresponding members in the corresponding file length array m_FileSize_Month to 0;

and 3.2, circularly calling the createFileDBM application to initialize the file group to the file pointer group m_mapfile H_Month, acquiring the length of each file, and assigning the length to the corresponding member in the length array m_FileSize_Month.

Preferably, the step 4 of searching the log and generating the index file according to the search condition specifically includes the following steps:

step 4.1, clicking the "load" or "search" button triggers the waitformultiplexing objects waiting semaphores;

step 4.2, ashing the searching button and the loading button, so as to avoid repeatedly triggering the semaphore before loading is finished;

step 4.3, checking whether an index file recordonly. Dat exists, and destroying if the index file recordonly. Dat exists;

step 4.4, creating an index file recordonly. Dat, and recording a file pointer of the index file to class member m_fpselected_record;

step 4.5, circularly calling SearchFromOnLogFlieRecord according to the number of files, sequentially browsing and reading the files in the range to be browsed, screening all logs, and recording the log addresses meeting the conditions into m_fpselected_record;

step 4.6, calculating to obtain the number nRecordCount of the items to be displayed according to the size of the index file, and setting the number of the items of the virtual list as nRecordCount;

step 4.7, close the file pointer m_fpselected_record and normalize the "load" and "search" buttons.

Preferably, the calling SearchFromOneLogFlieRecord in the step 4.5 specifically includes the following steps:

step 4.5.1, judging that m_fpselected_record is empty, and if the m_fpselected_record is empty, exiting;

step 4.5.2, calling a Windows interface MapViewOfFile, and mapping a corresponding file on a hard disk into a memory pointer mapH according to the size of m_Allocation Granularity bytes each time;

step 4.5.3, calling DealWithLogItemRecord to process the data block with the m_Allocation Granularity byte size read out by MapViewOfFile;

4.5.4, judging whether the end of the file is reached, and if so, exiting the program; if not, go to step 4.5.2 to read the next data block of the file.

Preferably, the calling the dealwith log itemrecord function in step 4.5.3 specifically includes the following steps:

4.5.3.1, judging whether the input character stream is an initial data block of the log file, if not, copying the input data stream to '\r' and the previous data content to a character array TAILContents left by the previous block, enabling the TAILContents to be a complete record, and calling MatchStrInStr and ParseFilterContentRecord for screening;

step 4.5.3.2, recording the untreated byte index as index;

step 4.5.3.3, polling backward from the index byte, recording as a complete record when encountering '\r';

4.5.3.4, judging whether the record is complete, if not, assigning the rest content to the tailcontent;

4.5.3.5, judging whether the keyword in the search condition is empty, and if not, calling matchstrlnstr to reject log records which do not contain the keyword;

step 4.5.3.6, calling ParseFilterContentRecord to screen out log records meeting the conditions according to types;

4.5.3.7, judging whether the end of the file is reached, and if so, exiting;

step 4.5.3.8, go to step 4.5.3.3.

Preferably, the step 4.5.3.1 of calling parsefilterContentRecord for parsing specifically includes the following steps:

step 4.5.3.1.1, firstly, defining an input structure of a function:

step 4.5.3.1.2, initializing an index value ind and a count value count;

step 4.5.3.1.3, determining whether ind is smaller than the recorded maximum length content, if yes, executing step 4.5.3.1.4, if not, indicating that browsing is completed, and exiting the program;

step 4.5.3.1.4, determine the tailcontent [ ind ] ++! If yes, ind++, go to step 4.5.3.1.2, if not, go to step 4.5.3.1.5;

step 4.5.3.1.5, determining whether the count can filter out the specific value of the record type, if yes, executing step 4.5.3.1.7, and if not, executing step 4.5.3.1.6;

step 4.5.3.1.6, count++, ind+=3, and go to step 4.5.3.1.2;

step 4.5.3.1.7, extracting the record type from the record, storing the record type in a variable typecur, and comparing the record type with the currently screened record type;

step 4.5.3.1.8, judging whether the record type typecur meets the type screening requirement, if not, returning to-1, exiting the program, and if so, executing step 4.5.3.1.9;

step 4.5.3.1.9, record the index value Fileindex of the log file, the data block index value map_data_offset, and the offset tail_offset in the data block into recordonly.

Preferably, the input structure of the definition function is specifically:

tailcontent: a pointer for recording the content;

contentinen: the maximum length of one record;

map_data_offset: recording a file data block index of a log file;

tailoffset: recording the offset of the data block;

fp: a file pointer to index the file recordonly;

type: a value of the screening record type input by the interface;

fileindex: the log file is at the index value of the file list.

Preferably, the calculating the number nRecordCount of the entries to be displayed according to the size of the index file specifically includes the following steps:

step 9.1, firstly, taking a record index value iItemIndx to be displayed as input;

step 9.2, calculating according to the iItemIndx to obtain a starting address for moving the m_fpselected to the segment to be read;

step 9.3, reading Fileindex, map_data_offset, and tail_offset from m_fpselected_record;

step 9.4, the corresponding file pointer mapfilehandle and file size FileSize are fetched from the file pointer array m_mapfile H_Month [ ] and the file size array m_filesize_Month [ ];

step 9.5, calling a MapViewOfFile to directly map the content in the log file to a character string pointer m_mapH;

step 9.6, checking whether the content in the map_data_offset and the offset tail_offset of the current data block is enough to read the current line, namely, if the log is just the end of the data block, whether the reading is complete or not, if yes, turning to step 9.7, and if not, turning to step 9.8;

step 9.7, calling GetLine1, analyzing the content in the GetLine1 to the pre, and transferring to step 9.10;

step 9.8, backing up the incomplete data of the tail block, using MapViewOfFile to read the next block of file data, and assigning the head content of the read next block to the front part of the tail data of the previous block to form a complete data record;

step 9.9, calling GetLine2 and analyzing the content in the GetLine2 into the pre;

and 9.10, exiting the program.

Compared with the prior art, the invention has the following advantages:

1. the invention adopts the technical scheme of self file mapping provided by Windows to read the log file, and the efficiency is much higher than that of the traditional IO stream. A memory mapped file is a mapping from one file to a process address space. In Win32, each process has its own address space, and one process cannot easily access data in the address space of another process, so it cannot do so like 16-bit Windows. The Win32 system allows multiple processes (running on the same computer) to share data using memory mapped files. Thus, the data in the file can be accessed by the memory read/write instruction instead of the I/O system functions such as ReadFile and WriteFile, thereby improving the file access speed. Traditional IO streaming operations make copies of data, which first copy the file contents from the hard disk to a buffer in kernel space, and then copy the data to user space, in which process two copies of data are actually made. The method of direct mapping the file directly maps the file address to the user space, so the interrupt processing function directly copies the file from the hard disk to the user space according to the mapping relation, and only performs one data copy. Therefore, the efficiency of memory mapping reading files is much higher than that of conventional IO streams.

2. The invention adopts the technical scheme of self file mapping provided by Windows to read the log file, thereby being beneficial to saving the memory space. The memory mapped file is a file mapped into the process' address space using virtual memory, after which the process manipulates the file as if it were manipulating the address of the process space. The middle does not need to load the content of the log into the memory, thereby greatly saving the program memory.

3. The invention adopts the technical scheme of self file mapping provided by Windows to read the log file, and completely breaks through the limitation of the size of the log file on the program. This is particularly appropriate for situations where the log file is odd and even in some more specific scenarios.

4. The invention adopts the technical scheme of self file mapping provided by Windows to read the log file, and the efficiency improving effect more obviously ensures the running efficiency of the main program under the condition of poor PC performance. The conventional method for loading logs by using IO streams needs to load log files into a memory. As log files are more and more loaded, the smaller the remaining memory space is available for the PC. The residual memory of the PC directly affects the program operation efficiency. The log file is read by adopting the technical scheme of the self file mapping provided by Windows, and any extra memory space is not loaded, so that enough residual space is provided for the operation of the main program, and the operation efficiency of the main program is further ensured.

5. The method for establishing the log index is beneficial to quickly positioning the addresses of the log files to be displayed, and does not need to search all log file spaces during display, so that the log reading efficiency is effectively improved. When searching proper journal entries, the addresses of the entries of the journal to be displayed are integrated into a readable index binary file. When each display is performed, firstly, the address information recorded in the log file is read from the index binary file according to the relative position, and then the log entry is rapidly positioned and read according to the read address information, so that the efficiency is greatly improved.

6. When the log is displayed, the method adopts the form of the virtual list, thereby saving a large number of controls which are needed to be loaded on the MFC controls. When displaying content in a common list, the log entries themselves need to be loaded onto the list control. This often results in the MFC control itself not being able to withstand an excessive amount of logging, resulting in a crash of the program. In the form of a virtual list, only twenty bars that need to be displayed on the interface need to be loaded per MFC control. Less memory is required to be consumed, so that a light and fast program is developed.

Drawings

FIG. 1 is a schematic diagram of a process flow;

FIG. 2 is an initializing file pointer diagram;

FIG. 3 is a flow chart for searching logs and generating index files according to established search conditions;

FIG. 4 is a flowchart for generating an index file by browsing a single file;

FIG. 5 is a flowchart of the function DealWithLogItemRecord;

FIG. 6 is a MatchStrInStr flow chart;

FIG. 7 is a ParseFilterContentRecord flowchart;

FIG. 8 is a flowchart for quickly obtaining log entries to be displayed;

FIG. 9 is a GetLine1 flowchart;

fig. 10 is a GetLine2 flow chart.

Detailed Description

The following description of the technical solutions in the embodiments of the present invention will be clear and complete, and it is obvious that the described embodiments are some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the present invention without making any inventive effort, shall fall within the scope of the present invention.

The main flow of the program of the invention is shown in figure 1, the method adopts a method of independently calling a thread to realize the functions, and comprises the following steps:

step 100, setting search preconditions;

step 101, triggering signals to enable functions to start executing starting;

step 102, calling a function InitOneMonthFMap to initialize a file pointer and the like;

step 103, calling SearchbyTypeKeyWord to search all related log files in sequence according to the search condition, analyzing the content of the relevant log files, and recording the address information of the log entries meeting the requirements as a single index file recordonly.

Step 104, according to the size of the recordoly. Dat file, the recorded data volume calculates the number nrecodcount of logs to be displayed. Setting the number of items of the virtual list to be displayed as nRecordCount;

step 105, when the virtual list is displayed inside, call gettechnical description to acquire the log content that should be displayed in the line. The execution process is that the address value in the log text per se in the corresponding log entry content recorded in the recordonly. Dat is obtained by rapid calculation according to the line number, and the log is directly read from the log text per se according to the read address value, and then displayed on an interface;

if the search needs to be re-executed, the preconditions for the search need to be re-set, step 106 is executed.

The program must determine the set of files to open based on the time span. Too many file groups are opened, wasting resources. If too few file groups are opened, the function requirement cannot be met, and the process of initializing the file pointer in the invention is shown in fig. 2, and comprises the following steps:

step 201, checking whether members in the file pointer group m_mapfile h_Month are used, if so, closing the file, releasing the memory, and setting the corresponding members in the corresponding file length array m_filesize_Month to 0;

step 202, circularly calling a CreateFileDBM application to initialize a file group to a file pointer group m_mapfile H_Month, acquiring the length of each file, and assigning the length to a corresponding member in a length array m_FileSize_Month;

CreateFileDBM application mainly realizes the code as follows:

as shown in fig. 3, the process of searching the log and generating the index file according to the predetermined search condition of the present invention includes the steps of:

step 301, clicking the "load" or "search" button triggers the waitformultiple objects waiting semaphore;

step 302, ashing the search button and the load button, so as to avoid repeatedly triggering the semaphore before loading is finished;

step 303, checking whether there is a recordonly. Dat index file. If so, destroying;

step 304, creating a recordonly.dat file, and recording a file pointer to the class member m_fpselected_record;

step 305, circularly calling SearchFromOnLogFlieRecord according to the number of files, sequentially browsing and reading the files in the required browsing range in order, screening all logs, and recording the log address records meeting the conditions into m_fpselected_record;

step 306, calculating to obtain the number nRecordCount of the items to be displayed according to the size of the index file, and setting the number of the items of the virtual list as nRecordCount;

step 307, close the file pointer m_fpselected_record and normalize the "load" and "search" buttons.

FIG. 4 is a flowchart of the SearchFromOnLogFlieRecord mentioned in FIG. 3 in the flow of the present invention, which is responsible for browsing all logs in a single file to determine whether the log meets the requirement, and recording the log address in m_fpselected_record, comprising the following steps:

step 401, determine if m_fpselected_record is empty. If the device is empty, exiting;

step 402, a Windows interface MapViewOfFile is called, and a corresponding file on a hard disk is mapped into a memory pointer mapH according to the size of m_Allocation Granularity bytes each time;

step 403, calling DealWithLogItemRecord to process the data block with m_Allocation Granularity byte size read out by MapViewOfFile;

step 404, judging whether the end of the file is reached, if so, exiting the program; if not, go to step 402 where the next data block of the file is read.

Fig. 5 is a flow chart of the DealWithLogItemRecord function mentioned in fig. 4 in the program flow of the present invention. The DealWithLogItemRecord function is responsible for handling a block of data of size m_Allocation Granularity bytes, typically 64K. The whole sentence in the data block is directly processed, if the beginning and the end of the data block have record entries which are not complete, the whole sentence is processed together with the end of the last data block or the rest part of the next data block which is not complete record entry, and the method specifically comprises the following steps:

step 501, determining whether the input character stream is the initial data block of the log file? If not, the input data stream is copied to '\r', '\n' and the previous data content to the character array TAILContents left by the previous block, so that the TAILContents become a complete record, and MatchStrInStr and ParseFilterContentRecord are called for deletion;

step 502, recording an unprocessed byte index as an index;

step 503, polling backward from the index byte, recording as a complete record when encountering '\r "\n';

step 504, determine whether it is a complete record. If not, the rest content is assigned to the tailcontent;

step 505, judging whether the keyword in the search condition is empty, if not, calling matchstrlnstr to reject the log record which does not contain the keyword;

step 506, calling ParseFilterContentRecord to screen out log records meeting the conditions according to types;

step 507, if the end of the file is reached, exiting if the end of the file is reached;

step 508, go to 503.

Fig. 6 is a flow chart of matchstrinst referred to in flow chart 5 of the present invention. Matchstrinst performs the function of string matching. The effect is equivalent to str function. But str functions need to encounter '0' to be string ending. The character string read in the invention reads 64K bytes of content every time, and the middle part does not have an '\0' ending symbol, so if a str function is adopted, the stron function is inevitably out of range, and the function of realizing the character string searching by the matchstr is needed to be realized. The implementation code is as follows:

FIG. 7 is a flow chart of the ParseFilterContentRecord function referred to in FIG. 5 in the program flow of the present invention. ParseFilterContentRecord is responsible for parsing a complete log record of a line and matching according to the entered type value. If the matching is successful, the index address value of the log is recorded in the binary file recordonly. Dat, and the method comprises the following steps:

first, defining the input structure of a function:

tailcontent: a pointer to record the content.

Contentinen: the maximum length of one record.

map_data_offset: and recording the file data block index of the log file.

tailoffset: the offset of the data block where the record is located.

fp: a file pointer to index file recordonly.

type: the value of the filter record type input by the interface.

fileindex: the log file is at the index value of the file list.

Step 601, initializing an index value ind and a count value count;

step 602, determining whether ind is smaller than the record maximum length contentlen, if not, indicating that browsing is completed, and exiting the program;

step 603, if yes, determine the tailcontent [ ind ] ++! =', if yes, ind++, go to step 602;

step 604, if not, determining whether the count is a specific value that can filter out record types;

step 605, if not, count++, ind+=3, and go to step 602;

step 606, if yes, extracting the record type from the record, storing the record type into a variable typecur, and comparing the record type with the currently screened record type;

step 607, determining whether the record type typecur meets the type screening requirement; if not, returning to-1, and exiting the program;

step 608, if yes, recording the index value Fileindex of the log file, the data block index value map_data_offset, and the offset value tailoffset in the data block into the recordonly.

Fig. 2 to 7 described above describe how the required addresses of the satisfactory log records are recorded to the index file recordonly. As shown in fig. 8, the method for quickly obtaining the journal entry to be displayed through the index file recordonly.

Firstly, taking a recorded index value iItemIndx to be displayed as input;

step 701, calculating a file pointer offset according to an index value iItemIndx of a record to be displayed, and moving a file pointer m_fpselected_record of an index file to a start address of a segment to be read;

step 702, reading Fileindex, map_data_offset, and Tail_offset from m_fpselected_record;

step 703, fetching a corresponding file pointer mapfilehandle from a file pointer array m_mapfile h_monta [ ], and fetching a corresponding file size FileSize from a file size array m_filesize_monta [ ];

step 704, calling MapViewOfFile to directly map the content in the log file to a character string pointer m_mapH;

step 705, checking whether the content in the map_data_offset is enough to read the current line, i.e. the log is just the end of the data block, if yes, go to step 706; if not, go to step 707;

step 706, calling GetLine1 and parsing the content into pre, and turning to step 709;

step 707, backing up the incomplete data in the tail part, reading the next block of the file data by using the MapViewOfFile, and assigning the head content of the read next block to the front part of the tail data in the previous block to form a complete data record;

step 708, calling GetLine2 and resolving the content into pre;

step 709, exit the procedure.

Fig. 9 and 10 are flowcharts of GetLine1 and GetLine2, respectively. GetLine1 and GetLine2 are algorithms that extract and parse records from a data block according to the address of a particular record. The difference is that GetLine1 parses the record from the present chunk data. However, getLine2 is because the record is not completely recorded in the block data, and it is required that the end portion of the block data and the beginning portion of the next block data be spliced together before a complete record is formed and parsed into the data structure.

The GetLine1 partial code is implemented as follows:

the GetLine2 partial code is implemented as follows:

while the invention has been described with reference to certain preferred embodiments, it will be understood by those skilled in the art that various changes and substitutions of equivalents may be made and equivalents will be apparent to those skilled in the art without departing from the scope of the invention. Therefore, the protection scope of the invention is subject to the protection scope of the claims.

Claims

1. A method for reading and displaying an interlocking log based on Windows file mapping technology is characterized by comprising the following steps:

2. The method for reading the display interlock log based on the Windows file mapping technology according to claim 1, wherein the initializing the pointer for Windows file mapping in the step 3 specifically comprises the following steps:

3. The method for reading the display interlock log based on the Windows file mapping technology according to claim 1, wherein the step 4 of searching the log and generating the index file according to the search condition specifically comprises the steps of:

4. The method for reading the display interlock log based on the Windows file mapping technology according to claim 3, wherein the calling the searchfromonelog record in step 4.5 specifically comprises the following steps: