A decentralized method and system for collaborative document editing

Abstract

The present application relates to the technical field of data processing, in particular to a kind of decentralized document collaborative editing method and system, it is by comparing the configuration weight sequence of configuration factor in N client with the configuration weight threshold sequence of central node, obtain M candidate client each item is greater than the configuration weight threshold of central node;The weighted sum of the selection weight of configuration factor in each client in M client and configuration weight is obtained to obtain candidate weight, select the K of maximum candidate weight from M client as alternative client, finally with the selection weight of configuration factor as the order of priority, to select the alternative client of maximum configuration weight in the configuration factor of highest priority as central node;Avoid the problem that all collaborative editing processing operations are concentrated in the same server to process lag, also solve the problem that a server failure leads to large-scale paralysis and data security.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a decentralized collaborative document editing method and system. Background Technology

[0002] Collaborative document editing allows multiple clients to simultaneously modify the same document on a server, thereby updating the document in real time with the content edited by different users. For example... Figure 1 As shown, current document collaborative editing systems generally use a server as the central node, with multiple clients communicating with the server as user operation nodes. When multiple clients edit the same document, the server is responsible for all clients' conversion operations, permission verification, conflict handling, etc., and sends the results of the conversion operations back to all clients accessing the current document.

[0003] The above-mentioned collaborative document editing method has the following drawbacks: First, the server, as the central node, stores all data uniformly, which can easily cause lag or even crashes when the access volume is too high; second, once the server fails, it will lead to a large-scale paralysis; third, user data is completely concentrated in the central node, making it easy to become a target of attacks, and there are significant risks to data security. Summary of the Invention

[0004] To address the aforementioned technical problems, the present invention adopts the following technical solution: a decentralized collaborative document editing method, the method comprising:

[0005] S100, When N clients simultaneously edit the same document DOC, the server obtains the configuration weights CFG = {CFG1, CFG2, ..., CFG} of the N clients. i ,…,CFG N}, CFG i CFG represents the sequence of configuration weights for the configuration factors in the i-th client, where i ranges from 1 to N. i ={Cor i Mem i ,RU i ,RM i BW i}, Cor i Mem is the configuration weight for the number of CPU cores of the i-th client. i For the configuration weight of the memory capacity of the i-th client, RU i RM is the configuration weight for the CPU idle rate of the i-th client. i BW is the configuration weight for the memory idle rate of the i-th client. i This represents the configuration weight for the network bandwidth of the i-th client.

[0006] S200, server determines CFG i To obtain CFG, we check if each item in the sequence is greater than each item in the configuration weight threshold sequence CFG0 of the central node. i Each of these is greater than M candidate clients of each of CFG0; where CFG0 = {Cor0, Mem0, RU0, RM0, BW0}, Cor0 is the configuration weight threshold for the number of CPU cores of the central node, Mem0 is the configuration weight threshold for the memory capacity of the central node, RU0 is the configuration weight threshold for the CPU idle rate of the central node, RM0 is the configuration weight threshold for the memory idle rate of the central node, and BW0 is the configuration weight threshold for the network bandwidth of the central node.

[0007] S300, the configuration weight sequence CFG of the j-th candidate client among the M candidate clients. j The candidate weights cw are obtained by weighting and summing the weights of the configuration factor and the selection weights W. j The candidate weights corresponding to candidate clients M are cw = {cw1, ​​cw2, ..., cw}. j ,…,cw M In the selection process, the K candidate clients with the largest candidate weights are chosen, where the value of j ranges from 1 to M.

[0008] S400 uses the selection weight of configuration factors as the priority order, and selects the candidate client with the highest configuration weight among the K candidate clients as the central node for collaborative document editing.

[0009] Furthermore, the present invention provides a decentralized document collaborative editing system, the system comprising a processor and a non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores at least one instruction or at least one program, the at least one instruction or the at least one program being loaded and executed by the processor to realize a decentralized document collaborative editing method.

[0010] Compared with the prior art, the present invention has significant advantages. Through the above technical solution, the decentralized document collaborative editing method and system provided by the present invention achieves considerable technological progress and practicality, and has broad industrial application value. It has at least the following advantages:

[0011] This invention provides a decentralized, cross-platform document collaborative editing method and system. The system uses a server to obtain M candidate clients based on the configuration weight sequence of configuration factors in N clients and the configuration weight threshold sequence of the central node. Candidate weights are obtained based on the selection weight of configuration factors and the configuration weight of each of the M clients. The K clients with the highest candidate weights are selected as alternative clients from the M clients. Finally, the client with the highest configuration weight among the highest priority configuration factors is selected as the central node, using the selection weight of the configuration factors as the priority order. This central node replaces the role of the server in existing technologies. By selecting one central node from N clients accessing the same document, the system avoids the problem of excessive access volume leading to lag or even crashes caused by processing all collaborative editing on a single server. It also solves the data security problems of large-scale paralysis due to server failure and the vulnerability of data to attacks when all data is concentrated on a single server. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a flowchart of a decentralized collaborative document editing method provided in an embodiment of the present invention. Detailed Implementation

[0014] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0015] Please see Figure 1 It illustrates a flowchart of a decentralized collaborative document editing method, which includes:

[0016] S100, When N clients simultaneously edit the same document DOC, the server obtains the configuration weights CFG = {CFG1, CFG2, ..., CFG} of the N clients. i ,…,CFG N}, CFG i CFG represents the sequence of configuration weights for the configuration factors in the i-th client, where i ranges from 1 to N. i={Cor i Mem i ,RU i ,RM i BW i}, Cor i Mem is the configuration weight for the number of CPU cores of the i-th client. i For the configuration weight of the memory capacity of the i-th client, RU i RM is the configuration weight for the CPU idle rate of the i-th client. i BW is the configuration weight for the memory idle rate of the i-th client. i This represents the configuration weight for the network bandwidth of the i-th client.

[0017] It should be noted that in this embodiment of the invention, the server's role is solely to select a central node based on the configuration of the N clients, and the central node is responsible for the collaborative editing process of the N clients on the same document.

[0018] It should be noted that the number of CPU cores and memory capacity in the configuration weights are determined by the client's own configuration, while the CPU idle rate, memory idle rate and network bandwidth in the configuration weights can be obtained by testing or monitoring the corresponding configuration factors in the client using third-party tools.

[0019] As a preferred embodiment, the CFG i This is the normalized configuration weight sequence.

[0020] Optionally, normalization can be achieved by adjusting Cor... i Mem i RU i RM i and BW i Perform linear normalization or standard deviation normalization.

[0021] In a preferred embodiment, the communication between the N clients is a long-lived connection.

[0022] S200, server determines CFG i To obtain CFG, we check if each item in the sequence is greater than each item in the configuration weight threshold sequence CFG0 of the central node. i Each of these is greater than M candidate clients of each of CFG0; where CFG0 = {Cor0, Mem0, RU0, RM0, BW0}, Cor0 is the configuration weight threshold for the number of CPU cores of the central node, Mem0 is the configuration weight threshold for the memory capacity of the central node, RU0 is the configuration weight threshold for the CPU idle rate of the central node, RM0 is the configuration weight threshold for the memory idle rate of the central node, and BW0 is the configuration weight threshold for the network bandwidth of the central node.

[0023] Among them, CFG i Each term greater than CFG0 refers to: Cor i Greater than Cor0, Mem i Greater than Mem0, RU i Greater than RU0, RM i Greater than RM0 and BW i Greater than BW0.

[0024] It should be noted that the configuration weight threshold sequence CFG0 of the central node serves as the minimum criterion for selecting the central node. If CFG i If any one of the criteria is less than CFG0, then the corresponding client is considered not to meet the minimum requirements to be a central node.

[0025] The configuration weight threshold sequence CFG0 for the central node can be a preset weight threshold. Alternatively, CFG0 can be obtained by statistically analyzing the number of stutters during collaborative editing of historical central nodes, filtering out the R historical central nodes with the lowest stutter counts, and obtaining the average value of each historical configuration weight for the R historical central nodes.

[0026] S300, the configuration weight sequence CFG of the j-th candidate client among the M candidate clients. j The candidate weights cw are obtained by weighting and summing the weights of the configuration factor and the selection weights W. j The candidate weights corresponding to candidate clients M are cw = {cw1, ​​cw2, ..., cw}. j ,…,cw M In the selection process, the K candidate clients with the largest candidate weights are chosen, where the value of j ranges from 1 to M.

[0027] The selection weight W for configuration factors is a weight sequence of all configuration factors in the client, unrestricted by the client itself; the same configuration factor has the same selection weight across all clients. The selection weight W can be a preset value or an empirical value obtained through analysis of historical data. Specifically, W = {w1, w2, w3, w4, w5}, where w1 is the selection weight for the number of CPU cores, w2 is the selection weight for memory capacity, w3 is the selection weight for CPU idle rate, w4 is the selection weight for memory idle rate, and w5 is the selection weight for network bandwidth. CFG j The steps for weighted summation with W include: the result of the weighted summation is: cw j =w1×Cor i +w2×Mem i +w3×RU i +w4×RM i +w5×BW i .

[0028] As a preferred embodiment, S300 further includes:

[0029] S320, update the candidate weights cw based on the historical weights hw of the M candidate clients, where cw j The update steps include:

[0030] S322, obtain the number of historical operations Num performed by the j-th client on the document DOC within a preset time period. j Tim's cumulative duration of historical visits j The preset time period is a preset value, which can be specified as X hours in units of hours.

[0031] S324, according to Num j and Tim j Obtain historical weights hw j Among them, hw j respectively with Num j and Tim j Positive correlation.

[0032] S326, the previous CW j with hw j Multiplying them together yields the updated cw. j .

[0033] Understandably, assigning different historical weights to clients based on the number of times and duration of their operations on the same document, as recorded in the historical database, tilts the final selection towards clients with frequent and long-duration operations, resulting in a more stable central node. This is particularly suitable when N clients have identical hardware configurations and similar CPU and memory idle rates; in such cases, this historical weighting plays a dominant role, leading to the selection of clients that better suit the actual application scenario.

[0034] As a preferred embodiment, the hw j satisfy:

[0035] hw j =hw1(Num j )+hw2(Tim j ); where hw1(Num j ) is Num j First historical subweight, hw2(Tim j ) for Tim j The second historical subweight.

[0036] Where hw2(Tim j ) = exp(Tim j / (Tim1+Tim2+…Tim j …+Tim M ));

[0037] When Num j When = 0, hw1(Num j ) = 0; otherwise, hw1(Num j ) = ln(Num j ).

[0038] It is understandable that when Num j When it is small, ln(Num) j The function grows relatively quickly; when Num j When it increases to a certain value, ln(Num) j The rate at which the value of the function increases slows down and gradually stabilizes. That is, when the number of visits Num... j When a certain value is reached, their impact on the final weight becomes similar. As for access time, the longer the historical access duration, the more stable the node is, and the less likely it is to suddenly exit the overall collaborative editing system. This avoids the server repeatedly calculating and filtering new central nodes. Therefore, the cumulative online time of each client is calculated, and the weights of different clients are allocated according to the proportion of each client's corresponding cumulative time to the total cumulative time of all M candidate clients. An exponential function is then used to amplify and smooth the corresponding weights.

[0039] S400 uses the selection weight of configuration factors as the priority order, and selects the candidate client with the highest configuration weight among the K candidate clients as the central node for collaborative document editing.

[0040] It should be noted that the central node plays a role similar to that of a server in existing technologies, responsible for all client conversion operations, permission verification, conflict handling, etc., and sending the results of the conversion operations back to all clients accessing the current document.

[0041] In a preferred embodiment, S400 further includes:

[0042] S420: When the number of candidate clients with the largest configuration weight among the highest priority configuration factors is not unique, iterate through the candidate clients with the largest configuration weight among the next lower priority configuration factors according to priority order to select the unique candidate client as the central node.

[0043] As a preferred embodiment, S410 further includes:

[0044] S421, when the candidate client with the largest configuration weight among the configuration factors traversed according to the lowest priority is not unique, select the candidate client with the largest candidate weight among the largest candidate clients as the central node.

[0045] In a preferred embodiment, after step S400, the method further includes: S500, whereby the server reselects a central node when the number of N clients in the system changes or at preset intervals, in order to dynamically update the central node. It should be noted that the preset interval is a pre-defined time length, which can be specified in hours or minutes, and can be set by the user according to their needs.

[0046] In summary, this invention provides a decentralized, cross-platform document collaborative editing method. The server compares the configuration weight sequence of configuration factors in N clients with the configuration weight threshold sequence of the central node to obtain M candidate clients whose each item is greater than the configuration weight threshold of the central node. The selection weight of the configuration factor in each of the M clients is calculated and the weighted sum of the configuration weights to obtain the candidate weights. The K clients with the largest candidate weights are selected from the M clients as alternative clients. Finally, the selection weight of the configuration factor is used as the priority order to select the alternative client with the largest configuration weight among the highest priority configuration factors as the central node. The selected central node replaces the role of the server in the prior art. By selecting one central node from N clients accessing the same document, the problem of high access volume leading to lag or even crashes caused by concentrating all collaborative editing operations on a single server is avoided. It also solves the problem of large-scale paralysis caused by a single server failure and the vulnerability of a server to attacks when all data is concentrated on a single server.

[0047] Based on the same inventive concept as the above-described method embodiments, the present invention also provides a decentralized document collaborative editing system. The system includes a processor and a non-transitory computer-readable storage medium. The non-transitory computer-readable storage medium stores at least one instruction or at least one program. The at least one instruction or the at least one program is loaded and executed by the processor to implement a decentralized document collaborative editing method. One such decentralized document collaborative editing method has been described in detail in the above embodiments and will not be repeated here.

[0048] While specific embodiments of the invention have been described in detail by way of example, those skilled in the art should understand that the examples are for illustrative purposes only and not intended to limit the scope of the invention. It should also be understood that various modifications can be made to the embodiments without departing from the scope and spirit of the invention. The scope of the invention is defined by the appended claims.

Claims

1. A decentralized collaborative document editing method, characterized in that, The method includes: S100, When N clients simultaneously edit the same document DOC, the server obtains the configuration weights CFG={CFG1,CFG2,…,CFG…} of the N clients. i ,…,CFG N }, CFG i CFG represents the sequence of configuration weights for the configuration factors in the i-th client, where i ranges from 1 to N. i ={Cor i Mem i ,RU i ,RM i BW i }, Cor i Mem is the configuration weight for the number of CPU cores of the i-th client. i For the configuration weight of the memory capacity of the i-th client, RU i RM is the configuration weight for the CPU idle rate of the i-th client. i BW is the configuration weight for the memory idle rate of the i-th client. i The configuration weight for the network bandwidth of the i-th client; S200, server determines CFG i To obtain CFG, we check if each item in the sequence is greater than each item in the configuration weight threshold sequence CFG0 of the central node. i Each of these is greater than M candidate clients of each of CFG0; where CFG0={Cor0,Mem0,RU0,RM0,BW0}, Cor0 is the configuration weight threshold for the number of CPU cores of the central node, Mem0 is the configuration weight threshold for the memory capacity of the central node, RU0 is the configuration weight threshold for the CPU idle rate of the central node, RM0 is the configuration weight threshold for the memory idle rate of the central node, and BW0 is the configuration weight threshold for the network bandwidth of the central node. S300, the configuration weight sequence CFG of the j-th candidate client among the M candidate clients. j The candidate weights cw are obtained by weighting and summing the weights cw and w with the selection weights W of the configuration factor. j ; The candidate weights corresponding to candidate clients M are cw={cw1, ​​cw2,…,cw j ,…, cw M In the selection process, the K candidate clients with the largest candidate weights are chosen, where the value of j ranges from 1 to M; S400 uses the selection weight of configuration factors as the priority order, and selects the candidate client with the highest configuration weight among the K candidate clients as the central node for collaborative document editing. S300 further includes: S310, update the candidate weights cw based on the historical weights hw of the M candidate clients, where cw j The update steps include: S311, obtain the number of historical operations Num performed by the j-th client on the document DOC within a preset time period. j Tim's cumulative duration of historical visits j ; S312, according to Num j and Tim j Obtain historical weights hw j Among them, hw j respectively with Num j and Tim j Positive correlation; S313 will update the previous version of CW. j with hw j Multiplying them together yields the updated cw. j .

2. The method according to claim 1, characterized in that, The S400 also includes: S410: When the number of candidate clients with the largest configuration weight among the highest priority configuration factors is not unique, iterate through the candidate clients with the largest configuration weight among the next lower priority configuration factors according to priority order to select the unique candidate client as the central node.

3. The method according to claim 1, characterized in that, The S410 further includes: S411, when the candidate client with the largest configuration weight among the configuration factors traversed according to the lowest priority is not unique, select the candidate client with the largest candidate weight among the largest candidate clients as the central node.

4. The method according to claim 1, characterized in that, The CFG i This is the normalized configuration weight sequence.

5. The method according to claim 4, characterized in that, The normalization method is to use Cor i Mem i RU i RM i and BW i Linear normalization, or standard deviation normalization.

6. The method according to claim 1, characterized in that, Communication between N clients is via a long-lived connection.

7. The method according to claim 1, characterized in that, The hw j satisfy: hw j = hw1(Num j )+hw2(Tim j ); where hw j Let Num be the historical weight of the j-th client. j Let be the number of historical operations performed by the j-th client on the document DOC within a preset time period; Tim j This represents the cumulative duration of historical accesses to the document DOC by the j-th client within a preset time period; Where hw2(Tim j )=exp(Tim j / (Tim1+Tim2+…Tim j …+Tim M )); When Num j When =0, hw1(Num j )=0; otherwise, hw1(Num j )=ln(Num j ).

8. The method according to claim 1, characterized in that, Following step S400, the method further includes: S500: When the number of N clients in the system changes or at preset intervals, the server reselects the central node.

9. A decentralized document collaborative editing system, characterized in that, The system includes a processor and a non-transitory computer-readable storage medium storing at least one instruction or at least one program, the at least one instruction or the at least one program being loaded and executed by the processor to implement the method as described in any one of claims 1-8.

Images