A multi-module program automatic updating method based on a P2P architecture

Abstract

The application discloses a multi-module program automatic updating method based on a P2P architecture, which does not need a preset server or a mediation device, broadcasts program version information among network nodes, compares program versions autonomously, generates updating requirements and strategies according to comparison results, and finally completes program automatic updating. Meanwhile, when the updating requirements and strategies are formulated, the application mainly considers constraint relations among module program versions, and once a module program updating fails, the program version rollback work of associated modules can be selectively completed according to the constraint relations.

Description

Technical Field

[0001] This invention belongs to the field of automatic program update technology, and in particular relates to a multi-module automatic program update method based on P2P architecture. Background Technology

[0002] Internet devices typically employ a client / server (C / S) architecture for program updates. This architecture centers on a server, with clients connecting via the internet to create update links. New program versions can be pre-stored on the server or other intermediary devices. When a node needs an update, it can quickly request it from the server upon connecting to the network. Many wireless networks continue to use the C / S architecture. However, for distributed networks, the lack of fixed infrastructure makes program updates difficult. The C / S architecture relies on servers or fixed nodes for updates. Without server support, client connections cannot autonomously determine when to update, significantly reducing update flexibility. Furthermore, existing program updates are single-module updates. If a node device needs updates for multiple modules, multiple single-module updates are performed. Therefore, this method is only suitable for simple devices where module version constraints do not exist. Summary of the Invention

[0003] The purpose of this invention is to solve the problems mentioned in the background art above, and to provide a method for automatic updating of multi-module programs based on P2P architecture, which is mainly applicable to multi-module wireless network devices without infrastructure support.

[0004] To achieve the objectives of this invention, a method for automatic updating of multi-module programs based on a P2P architecture is disclosed, which enables automatic updates without the need for a pre-set server or intermediary device. Let the total number of nodes in the network be m, and the number of modules in each node be n. The update process for a node in the wireless network includes the following steps:

[0005] S11, Start the node device, check the program update register. If the register status is "reboot requires update", change the register status to "boot reboot without update" and proceed to step S17; otherwise, proceed to step S12.

[0006] S12, broadcast the version comparison packet of this node, and receive the version comparison packets broadcast by other nodes, organize the information in the version comparison packets of all nodes, and form a version comparison table;

[0007] S13. Based on the compiled version comparison table, determine if any modules need to be updated. If no modules need to be updated, wait for a fixed period of time and proceed to step S12. If any modules need to be updated, proceed to step S14.

[0008] S14. Calculate the update strategy based on the constraints in the version comparison table and send an update request packet to the corresponding node.

[0009] S15, Receive the update program sent by the corresponding node;

[0010] S16, determine the update mode set by the node. If the current update mode set by the node is "update immediately", proceed to step S17. If the current update mode set by the node is "update on restart", proceed to step S111.

[0011] S17, back up the program in the module to be updated. After the backup is complete, start the update, wait for the update to complete, and perform program verification and comparison.

[0012] S18, if the program comparison is successful, proceed to step S19; if the program comparison is unsuccessful, proceed to step S110.

[0013] S19, Read the version of each module in the node, update the version information, overwrite the original version information, and go to step S12;

[0014] S110, Selectively roll back versions based on the constraints between versions of each module. After the rollback is completed, proceed to step S19.

[0015] S111, Backup and update program, change the status of update register to "Update required for restart", proceed to step S12;

[0016] Furthermore, in step S12, a version comparison packet is sent under the following circumstances:

[0017] S121, When a new node joins the network, the new node and all nodes in the original network broadcast a version comparison packet;

[0018] S122: When no new nodes join the network, under the condition of the entire network at the same time, all nodes broadcast version comparison packets at fixed intervals.

[0019] Furthermore, in step S12, the specific message content of the version comparison packet is as follows:

[0020] The version comparison package contains the unique identifier of its own node, the number of modules n in the node, the version of the first module and its constraints with other modules, the version of the second module and its constraints with other modules, and so on up to the version of the nth module and its constraints with other modules.

[0021] Furthermore, in step S12, the specific format of the version comparison table is as follows:

[0022] The version comparison table includes the comparison module number, the unique identifier of each node, the comparison module version of each node, and the constraint relationship between other modules in each node and the comparison module.

[0023] Furthermore, in step S14, the specific calculation method for the update strategy is as follows:

[0024] S141, a module to be updated calculates an update strategy based on the version number of the module to be updated in each node of the version comparison table. When multiple nodes have newer versions of the module to be updated, the node with the largest version number is selected and an update request package is sent to it.

[0025] S142, a module to be updated calculates an update strategy based on the version number of the module to be updated in each node of the version comparison table. When multiple nodes have the same version number of the module to be updated, and the version number is the largest, the node with the smallest unique identifier is selected and an update request packet is sent to it.

[0026] Furthermore, in step S14, the specific message content of the updated request packet is as follows:

[0027] The unique identifier of the requesting node, the unique identifier of the requested node, the application requirements of the first module, the application requirements of the second module, and so on up to the application requirements of the nth module.

[0028] Furthermore, in step S14, the specific steps for a node in the wireless network to send an update procedure are as follows:

[0029] S143, received an update request packet from another node in the network;

[0030] S144, Read the program of the corresponding module according to the contents of the update request package;

[0031] S145, based on the contents of the update request package, send the corresponding module's program to the corresponding node.

[0032] Furthermore, in step S110, the specific steps for version rollback are as follows:

[0033] S1101, when a module fails to verify, find the version comparison package of that node, and determine whether other modules should be rolled back based on the constraints between modules;

[0034] S1102, If the version rolled back from the module that failed the verification is not within the constraints of the associated module, the associated module and the module that failed the update will be rolled back together.

[0035] S1103: If the rolled-back version of a module that failed the verification is still within the constraints of the associated module, then the associated module will not be rolled back.

[0036] S1104: When there are no constraints between a module that failed to update and a module that succeeded in updating, the module that succeeded in updating will not be rolled back.

[0037] A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. The steps of an automatic update method for a multi-module program based on a P2P architecture are described when the processor executes the computer program.

[0038] A computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of a method for automatically updating a multi-module program based on a P2P architecture.

[0039] Compared with the prior art, the significant progress of the present invention is as follows: 1) It does not require a preset server or intermediate equipment. It can automatically complete the comparison of program versions by broadcasting program version information between network nodes, and generate update requirements and strategies based on the comparison results, and finally complete the automatic program update. 2) When formulating update requirements and strategies, the constraint relationship between program versions of each module is taken into account. Once the program update of a certain module fails, the program version rollback of the associated modules can be selectively completed according to the constraint relationship.

[0040] To more clearly illustrate the functional characteristics of the present invention, the following description is provided in conjunction with the accompanying drawings and specific embodiments. Attached Figure Description

[0041] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0042] Figure 1 A schematic diagram of the update process for a specific node.

[0043] Figure 2 A schematic diagram of the node sending update procedure in a wireless network.

[0044] Figure 3 Schematic diagram of node networking method.

[0045] Figure 4 A diagram illustrating the content of the version comparison packet.

[0046] Figure 5 Version comparison table content diagram.

[0047] Figure 6 A diagram illustrating the content of an update request packet.

[0048] Figure 7 Schematic diagram of version rollback judgment process. Detailed Implementation

[0049] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. 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.

[0050] This invention is mainly applied to multi-module communication systems based on P2P architecture without basic network infrastructure, and performs automatic comparison, distribution and update of modules undertaking communication tasks.

[0051] In this invention, each node has a unique identifier, A, B, C, ..., and the size of the unique identifier is A < B < C < ..., each module is numbered A, B, C, ..., and the version number is A3, B4, ..., where version number A3 represents version 3 of module A program and B4 represents version 4 of module B program.

[0052] In this invention, there are constraints between different versions of each module. All module versions are backward compatible to a limited extent. For example, versions A3-A5 of module A are compatible with versions B2-B6 of module B. If B7 is compatible with versions A3 and A4, then it must also be compatible with version A5. That is, if a version of module B is compatible with an intermediate version Ax of module A, then without any other constraints, the version of module B is compatible with versions from Ax to the latest version of module A.

[0053] In this invention, modules that have the above-mentioned constraint relationship are interconnected.

[0054] This invention provides a method for automatic updating of multi-module programs based on a P2P architecture, and the specific technical solution is as follows.

[0055] like Figure 1 As shown, the specific steps of the update process for a node in a wireless network are as follows:

[0056] S11, Start the node device, check the program update register. If the register status is "reboot requires update", change the register status to "boot reboot without update" and proceed to step S17; otherwise, proceed to step S12.

[0057] S12, broadcast the version comparison packet of this node, and receive the version comparison packets broadcast by other nodes, organize the information in the version comparison packets of all nodes, and form a version comparison table;

[0058] S13. Based on the compiled version comparison table, determine if any modules need to be updated. If no modules need to be updated, wait for a fixed period of time and proceed to step S12. If any modules need to be updated, proceed to step S14.

[0059] S14. Calculate the update strategy based on the constraints in the version comparison table and send an update request packet to the corresponding node.

[0060] S15, Receive the update program sent by the corresponding node;

[0061] S16, determine the update mode set by the node. If the current update mode set by the node is "update immediately", proceed to step S17. If the current update mode set by the node is "update on restart", proceed to step S111.

[0062] S17, back up the program in the module to be updated. After the backup is complete, start the update, wait for the update to complete, and perform program verification and comparison.

[0063] S18, if the program comparison is successful, proceed to step S19; if the program comparison is unsuccessful, proceed to step S110.

[0064] S19, Read the version of each module in the node, update the version information, overwrite the original version information, and go to step S12;

[0065] S110, Selectively roll back versions based on the constraints between versions of each module. After the rollback is completed, proceed to step S19.

[0066] S111, Backup and update program, change the status of update register to "Update required for restart", proceed to step S12;

[0067] Optionally, in some possible implementations, the specific steps of the node in the wireless network sending the update procedure in step S14 are as follows (e.g., Figure 2 As shown):

[0068] S143, received an update request packet from another node in the network;

[0069] S144, Read the program of the corresponding module according to the contents of the update request package;

[0070] S145, based on the contents of the update request package, send the corresponding module's program to the corresponding node.

[0071] Optionally, in some possible implementations, the specific timing of broadcasting the version comparison packet in step S12 is as follows:

[0072] S121, When a new node joins the network, the new node and all nodes in the original network broadcast a version comparison packet;

[0073] S122: When no new nodes join the network, under the condition of the entire network at the same time, all nodes broadcast version comparison packets at fixed intervals.

[0074] Optionally, in some possible implementations, the specific message content of the version comparison packet in step S12 is as follows (e.g., Figure 4 As shown):

[0075] The version comparison package contains the unique identifier of its own node, the number of modules n in the node, the version of the first module and its constraints with other modules, the version of the second module and its constraints with other modules, and so on up to the version of the nth module and its constraints with other modules.

[0076] Optionally, in some possible implementations, the specific format of the version comparison table in step S12 is as follows (e.g., Figure 5 As shown):

[0077] The version comparison table includes the comparison module number, the unique identifier of each node, the comparison module version of each node, and the constraint relationship between other modules in each node and the comparison module.

[0078] Optionally, in some possible implementations, the specific calculation method of the update strategy in step S14 is as follows:

[0079] S141, a module to be updated calculates an update strategy based on the version number of the module to be updated in each node of the version comparison table. When multiple nodes have newer versions of the module to be updated, the node with the largest version number is selected and an update request package is sent to it.

[0080] S142, a module to be updated calculates an update strategy based on the version number of the module to be updated in each node of the version comparison table. When multiple nodes have the same version number of the module to be updated, and the version number is the largest, the node with the smallest unique identifier is selected and an update request packet is sent to it.

[0081] Optionally, in some possible implementations, in step S14, the specific message content of the updated request packet is as follows (e.g., Figure 6 As shown):

[0082] The unique identifier of the requesting node, the unique identifier of the requested node, the application requirements of the first module, the application requirements of the second module, and so on up to the application requirements of the nth module.

[0083] Optionally, in some possible implementations, the specific steps of version rollback in step S110 are as follows (e.g., Figure 7 As shown):

[0084] S1101, when a module fails to verify, find the version comparison package of that node, and determine whether other modules should be rolled back based on the constraints between modules;

[0085] S1102, If the version rolled back from the module that failed the verification is not within the constraints of the associated module, the associated module and the module that failed the update will be rolled back together.

[0086] S1103: If the rolled-back version of a module that failed the verification is still within the constraints of the associated module, then the associated module will not be rolled back.

[0087] S1104: When there are no constraints between a module that failed to update and a module that succeeded in updating, the module that succeeded in updating will not be rolled back.

[0088] Example 1

[0089] Implementation Example 1: Automatic update and verification of correctness across all nodes in the network. The network topology of nodes A, B, and C is as follows: Figure 3 As shown, let each of the three nodes, A, B, and C, have four modules, namely A, B, C, and D. The versions of each module are arranged sequentially starting from 1, written as A1, A2, B2, C3, etc. The larger the number, the newer the version.

[0090] Let the module versions of node A be A2, B3, C2, D5, the module versions of node B be A3, B5, C2, D4, and the module versions of node C be A3, B4, C2, D4. The constraints of module A are [A2, B3] and [A3, (B4, B5)], and the constraint of module C is [C2, (D4, D5)]. That is, version A2 of module A is compatible with version B3 of module B, and version A3 of module A is compatible with versions B4 and B5 of module B; version C2 of module C is compatible with versions D4 and D5 of module D; there are no constraints between modules A and B and between modules C and D.

[0091] Step 1: Start up three nodes, A, B, and C, and check the program to update the registers. All of them show "restart without updating".

[0092] Step 2: Nodes A, B, and C begin networking. When networking is successful, the networking mode is as follows: Figure 3 As shown, the three nodes broadcast a version comparison packet, the contents of which are as follows: Figure 4 As shown, taking node B as an example, the following table can be obtained. In the second row, the version of modules C and D is 0, which means that module A is not constrained by the versions of modules C and D. In the other rows, the module version is 0, which also means that the module is not constrained by the version of the module with version 0.

[0093]

[0094] After node B receives the version comparison packets sent by nodes A and C, it can compile the following version comparison table.

[0095]

[0096] Step 3: Based on the version comparison table, identify the modules that need to be updated.

[0097] Step 4: Based on the version comparison table, calculate the update strategy for node A as [A, B, A, A3][A, B, B5], the update strategy for node B as [B, A, D, D5], and the update strategy for node C as [C, B, B, B5][C, A, D, D5]. That is, node A sends update request packets A3 and B5 to node B; node B sends update request packets D5 to node A; node C sends update request packets B5 to node B and updates request packets D5 to node A. Taking node A sending update request packets A3 and B5 to node B as an example, the content of the update request packets is shown in the table below. In the update request packet, version 0 indicates that data for the corresponding module is not required.

[0098] First Second A3 B5 C0 D0

[0099] Based on the update request packets received by each node from the other two nodes, node A sends data D5 to nodes B and C; node B sends data A3 and B5 to node A, and data B5 to node C; node C does not need to send any data.

[0100] Step 5: Each node receives the updated data;

[0101] Step 6: Set nodes A and C to "update immediately" and node B to "update on restart". When a node has finished receiving update data from all modules to be updated, determine the update mode. If node B is set to "update on restart", it backs up the update program, changes the status of the update register to "update required on restart", and works normally, waiting for the next broadcast version comparison packet. If nodes A and C are set to "update immediately", they back up the currently running programs in the modules to be updated.

[0102] Step 7: After the backups of nodes A and C are completed, start the update, wait for the update to complete, and then perform program verification and comparison.

[0103] Step 8: All update modules for nodes A and C have been successfully verified.

[0104] Step 9: Read the versions of each module in nodes A and C, update the version information, and wait for the next broadcast version comparison packet.

[0105] Example 2

[0106] Implementation Example 2 involves automatic updates across all nodes in the network, with a process that includes verification failures. The network topology and module versions of nodes A, B, and C are the same as in Implementation Example 1.

[0107] Step 1: Start up three nodes, A, B, and C, and check the program to update the registers. All of them show "restart without updating".

[0108] Step 2: Nodes A, B, and C begin networking. When networking is successful, the networking mode is as follows: Figure 3 As shown, the three nodes broadcast a version comparison packet, the contents of which are as follows: Figure 4 As shown, taking node B as an example, we can obtain the following table. In the second row, the version of modules C and D is 0, which means that module A is not constrained by the versions of modules C and D. The same situation applies to the other rows where the module version is 0.

[0109]

[0110] After node B receives the version comparison packets sent by nodes A and C, it can compile the following version comparison table.

[0111]

[0112] Step 3: Based on the version comparison table, identify the modules that need to be updated.

[0113] Step 4: Based on the version comparison table, the update strategy for node A is determined to be [A, B, A, A3][A, B, B5], the update strategy for node B is [B, A, D, D5], and the update strategy for node C is [C, B, B, B5][C, A, D, D5]. That is, node A sends update request packets A3 and B5 to node B; node B sends update request packets D5 to node A; node C sends update request packets B5 to node B and updates request packets D5 to node A. Taking node A sending update request packets A3 and B5 to node B as an example, the content of the update request packets is shown in the table below. In the update request packet, version 0 indicates that data for the corresponding module is not required.

[0114] First Second A3 B5 C0 D0

[0115] Based on the update request packets received by each node from the other two nodes, node A sends data D5 to nodes B and C; node B sends data A3 and B5 to node A, and data B5 to node C; node C does not need to send any data.

[0116] Step 5: Each node receives the updated data;

[0117] Step 6: Set nodes A and C to "update immediately" and node B to "update on restart". When a node has finished receiving update data from all modules to be updated, determine the update mode. If node B is set to "update on restart", it backs up the update program, changes the status of the update register to "update required on restart", and works normally, waiting for the next broadcast version comparison packet. If nodes A and C are set to "update immediately", they back up the currently running programs in the modules to be updated.

[0118] Step 7: After the backups of nodes A and C are completed, start the update, wait for the update to complete, and then perform program verification and comparison.

[0119] Step 8: Module B in node A failed verification, and module D in node C failed verification. The version comparison packages for the corresponding nodes were searched. It was calculated that because module B in node A needs to roll back from B5 to B3, but A3 and B3 are incompatible, module A needs to roll back along with module B. Because module D in node C needs to roll back from D5 to D4, but has no constraint relationship with module B, module B in node C does not need to roll back.

[0120] Step 9: Wait for the module rollback to complete, update the version information, and wait for the next broadcast version comparison package.

[0121] Example 3

[0122] Implementation Example 3 describes the execution process of a node with the update mode "update on restart". In Implementation Example 1, node B's update mode is "update on restart", and the description will be based on the state of node B in Implementation Example 1.

[0123] Step 1: Implement step 6 in Example 1. Node B backs up the update program, changes the status of the update register to "reboot requires update", works normally, and waits for the next broadcast version comparison package.

[0124] Step 2: Restart the B node system, read the register status as "Update required on restart", and change the register status to "Do not update on restart".

[0125] Step 3: Back up the program in the module to be updated. After the backup is complete, start the update, wait for the update to complete, and then perform program verification and comparison.

[0126] Step 4: All update modules of node B have been successfully verified.

[0127] Step 5: Read the versions of each module in node B, update the version information, and wait for the next broadcast version comparison packet.

[0128] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0129] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for automatic updating of multi-module programs based on a P2P architecture, characterized in that, The node update process in a wireless network includes the following steps: S11, Start the node device, check the program update register. If the register status is "reboot requires update", change the register status to "reboot does not update" and proceed to step S17; otherwise, proceed to step S12. S12, broadcast the version comparison packet of this node, and receive the version comparison packets broadcast by other nodes, organize the information in the version comparison packets of all nodes, and form a version comparison table; S13. Based on the compiled version comparison table, determine if any modules need to be updated. If no modules need to be updated, wait for a fixed period of time and proceed to step S12. If any modules need to be updated, proceed to step S14. S14. Calculate the update strategy based on the constraints in the version comparison table and send an update request packet to the corresponding node. S15, Receive the update program sent by the corresponding node; S16, determine the update mode set by the node. If the current update mode set by the node is "update immediately", proceed to step S17. If the current update mode set by the node is "update on restart", proceed to step S111. S17, back up the program in the module to be updated. After the backup is complete, start the update, wait for the update to complete, and perform program verification and comparison. S18, if the program comparison is successful, proceed to step S19; if the program comparison is unsuccessful, proceed to step S110. S19, Read the version of each module in the node, update the version information, overwrite the original version information, and go to step S12; S110, Selectively roll back versions based on the constraints between versions of each module. After the rollback is completed, proceed to step S19. S111, Backup and update program, change the status of update register to "Update required for restart", proceed to step S12; In step S14, the specific calculation method of the update strategy is as follows: S141, a module to be updated calculates an update strategy based on the version number of the module to be updated in each node of the version comparison table. When multiple nodes have newer versions of the module to be updated, the node with the largest version number is selected and an update request package is sent to it. S142, a module to be updated calculates the update strategy based on the version number of the module to be updated in each node of the version comparison table. When multiple nodes have the same version number of the module to be updated, and the version number is the largest, the node with the smallest unique identifier is selected and an update request packet is sent to it. In step S110, the specific steps for version rollback are as follows: S1101, when a module fails to verify, find the version comparison package of that node, and determine whether other modules should be rolled back based on the constraints between modules; S1102, If the version rolled back from the module that failed the verification is not within the constraints of the associated module, the associated module and the module that failed the update will be rolled back together. S1103: If the version of a module that failed the verification is rolled back is still within the constraints of the associated module, then the associated module will not be rolled back. S1104: When there are no constraints between a module that failed to update and a module that succeeded in updating, the module that succeeded in updating will not be rolled back.

2. The method for automatic updating of multi-module programs based on a P2P architecture according to claim 1, characterized in that, In step S12, a version comparison packet is sent under the following circumstances: S121, When a new node joins the network, the new node and all nodes in the original network broadcast a version comparison packet; S122: When no new nodes join the network, under the condition of the entire network at the same time, all nodes broadcast version comparison packets at fixed intervals.

3. The method for automatic updating of multi-module programs based on a P2P architecture according to claim 1, characterized in that, In step S12, the specific message content of the version comparison packet is as follows: The version comparison package contains the unique identifier of its own node, the number of modules n in the node, the version of the first module and its constraints with other modules, the version of the second module and its constraints with other modules, and so on up to the version of the nth module and its constraints with other modules.

4. The method for automatic updating of multi-module programs based on a P2P architecture according to claim 1, characterized in that, In step S12, the specific format of the version comparison table is as follows: The version comparison table includes the comparison module number, the unique identifier of each node, the comparison module version of each node, and the constraint relationship between other modules in each node and the comparison module.

5. The method for automatic updating of multi-module programs based on a P2P architecture according to claim 1, characterized in that, In step S14, the specific message content of the update request packet is as follows: The unique identifier of the requesting node, the unique identifier of the requested node, the application requirements of the first module, the application requirements of the second module, and so on up to the application requirements of the nth module.

6. The method for automatic updating of multi-module programs based on a P2P architecture according to claim 1, characterized in that, In step S14, the specific steps for a node in the wireless network to send an update procedure are as follows: S143, received an update request packet from another node in the network; S144, Read the program of the corresponding module according to the contents of the update request package; S145, based on the contents of the update request package, send the corresponding module's program to the corresponding node.

7. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images