WO2012155645A1 - 基于p2p的无盘设备的网络启动方法及系统 - Google Patents
基于p2p的无盘设备的网络启动方法及系统 Download PDFInfo
- Publication number
- WO2012155645A1 WO2012155645A1 PCT/CN2012/072566 CN2012072566W WO2012155645A1 WO 2012155645 A1 WO2012155645 A1 WO 2012155645A1 CN 2012072566 W CN2012072566 W CN 2012072566W WO 2012155645 A1 WO2012155645 A1 WO 2012155645A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- version
- network
- diskless
- file
- devices
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
- G06F9/4416—Network booting; Remote initial program loading [RIPL]
Definitions
- the present invention relates to a version management and network booting technology for a diskless device, and more particularly to a network booting method and system for a diskless device based on a peer-to-peer (P2P, Peer-to-Peer). Background technique
- common version startup methods include disk device boot and diskless device boot.
- the disk device completes the device startup by using the version file stored in its own storage medium; the diskless device transmits the file to the local device through the network, and then runs locally to complete the device startup.
- the disk device has the advantage of not occupying network resources and being relatively stable. However, each device needs its own storage medium, which results in relatively high production cost.
- the version read and store are completely read and written by RAM. Compared with the flash reading and writing, the version reading and writing speed is greatly improved, and the version upgrade time is shortened. However, all the internals are required.
- the network device After the network device is powered on, it will go to the same server to obtain the version, which will lead to network congestion and increased server pressure. If multiple devices are in parallel, it will be queued, which will affect the overall network startup speed, especially when there is a problem with the server. This will cause the entire network device to be paralyzed and the reliability is not high.
- the object of the present invention is to provide a network booting method and system for a diskless device based on P2P, which solves the problem of high equipment production cost and slow device startup speed in the network.
- the present invention provides a P2P-based network booting method for a diskless device, the method comprising:
- the version request broadcast is sent to the other devices in the network. At least one device in the network responds to the version request broadcast message, and sends a version request response message to the diskless device.
- the diskless device obtains a version file from a device that made the response according to the received version request response message, and completes booting using the version file.
- the version request broadcast message includes a version type name and a version identifier of the requested version file.
- the at least one device in the network sends a version request response message to the diskless device in response to the version request broadcast message, including:
- At least one device in the network receives the version request broadcast message and parses it to obtain a version type name and a version identifier; compares the version type name and the version identifier with local version information, and when matching, according to the capability of transmitting the version by itself Sending a version request response message containing local version information and resource usage to the diskless device.
- the diskless device obtains a version file from a device that makes the response according to the version request response message, and completes the startup by using the version file, including:
- the diskless device receives at least one version request response message from another device within a predetermined time, and selects the three devices that respond first;
- the version file is obtained from the device;
- the The method also includes a version verification step;
- the step of verifying the version includes: after the diskless device obtains the version file, comparing the version header of the version file with the version information in the version request response message; if yes, starting the version file, otherwise, re-directing Other devices in the network request version files.
- the method further includes: if the diskless device obtains the version file timeout, re-requesting the version file to other devices in the network, and performing a breakpoint transmission of the version file.
- the version file has a version header
- the version header includes a version type name, a version identifier, a version generation time, and a version size.
- the other device comprises other diskless devices and/or local disk devices and/or aggregation devices with storage media.
- the network is an intranet of the access network.
- the present invention further provides a P2P-based network booting system for a diskless device, the system comprising:
- a version requesting module of the diskless device configured to send a version request broadcast message to other devices in the network during the booting process of the diskless device in the network;
- the request response module on the other device is configured to send a version request response message to the diskless device in response to the version request broadcast message;
- a version obtaining module of the diskless device configured to obtain a version file from a device that makes the response according to the received version request response message, and use the version file to complete the startup.
- the invention utilizes the P2P technology to make the network startup no longer rely on a single device or several devices, and the average resource utilization rate is reduced, and the specific network pressure is reduced. Equipment reliability, reduced equipment production costs, and increased equipment startup speed. DRAWINGS
- FIG. 1 is a flowchart of implementing a network startup method of a P2P-based diskless device according to the present invention
- FIG. 2 is a version structure diagram provided by the present invention
- FIG. 3 is a flow chart of network startup of a P2P-based diskless device according to the present invention.
- FIG. 4 is a network topology diagram of a P2P-based diskless device according to a first embodiment of the present invention
- FIG. 5 is a network topology diagram of a P2P-based diskless device according to a second embodiment of the present invention. detailed description
- P2P technology refers to point-to-point network transmission.
- each device is a server, and each is also a client.
- the device can find the resources it needs on the network as needed, and select the server to download and transfer according to specific rules.
- the invention provides a P2P-based network booting method for a diskless device.
- a method of setting a special server in the startup process of the original diskless device is eliminated, so that all devices running the same version of the file in the network are You can use the relevant version files for other diskless devices, and you are also the client. You can ask other devices for the version files you need.
- the P2P-based network of diskless devices is specifically: a network consisting of diskless devices running the same version of files on an intranet of the access network.
- the survival of all the devices in the network depends on the devices of the same type. When a device restarts or is abnormally powered off, the device restarts during the restart process.
- the network startup method of the P2P-based diskless device provided by the present invention includes the following steps:
- Step 101 During the startup of the diskless device in the network, send the version to other devices in the network. Ask for a broadcast message.
- the version request broadcast message includes a version type name and a version identifier of the requested version file.
- Step 102 At least one device in the network sends a version request response message to the diskless device in response to the version request broadcast message.
- the step 102 includes: at least one device in the network receives the version request broadcast message and parses, obtains a version type name and a version identifier; compares the version type name and the version identifier with local version information, and when matching, according to The self-transmission version capability transmits a version request response message including local version information and resource usage to the diskless device.
- Step 103 The diskless device obtains a version file from a device that makes the response according to the version request response message, and completes the startup by using the version file.
- the step 103 includes: the diskless device receives at least one version request response message from another device within a predetermined time, selects three devices that respond first; and uses the response message according to the version to use resources in the three devices.
- the device with the lowest rate sends a version upgrade confirmation request, and obtains a version file; using the version file to complete the booting of the diskless device.
- the step 103 further includes: after the diskless device obtains the version file, comparing the version header of the version file with the version information in the version request response message; if yes, starting the version file, otherwise, re-inward Other devices on the network request version files.
- the diskless device obtains the version file timeout, the version file is requested again from other devices in the network, and the version file is resumed by the breakpoint.
- the above version file has a version header, and the version header includes a version type name, a version identifier, a version generation time, and a version size.
- the present invention further provides a P2P-based network booting system for a diskless device, the system comprising: a version requesting module of a diskless device, a version obtaining module of a diskless device, and other than the diskless device a request response module on the device;
- a version requesting module of the diskless device configured to send a version request broadcast message to other devices in the network during the booting process of the diskless device in the network;
- the request response module on the other device is configured to send a version request response message to the diskless device in response to the version request broadcast message;
- a version obtaining module of the diskless device configured to obtain a version file from a device that makes the response according to the received version request response message, and use the version file to complete the startup.
- the above network is an intranet of the access network.
- FIG. 2 shows a block diagram of the version file provided by the present invention.
- the version file used in the device of the present invention needs to have a specific version file identifier, that is, a version header.
- the version header is located at the forefront of the binary version file and is generated by the version header generation tool, including some specific identifiers, such as the version type name (identifying the device type), the version identifier (identifying the version number), the version generation time, the version size, and the like. . These IDs are used for version verification and version upgrade protection during the version upgrade of the device.
- the version header only the existence of the version header is described. Since the version files generated by different operating systems are quite different, the binary version file is used instead, and is no longer refined for a certain product.
- the version file After the version file is transmitted to the diskless device through the network, it is saved to a specific memory local to the diskless device (usually using high-end reserved memory, that is, high-end memory), and then the version file is decompressed from the specific memory to the version running. The specified memory address is run to start the device. It should be noted that the version file obtained through network transmission needs to be kept here to be used for other device version upgrades.
- the device that meets some memory resources is limited, the version file is decompressed. After running, only the version fragments can be saved in the high-end memory for distributed storage.
- FIG. 3 shows a specific flow chart of the network booting of the P2P-based diskless device of the present invention. As shown in FIG. 3, the device is divided into a device as a server-side identity and a device as a client identity.
- the diskless device After the diskless device is restarted as a client, since it does not have a storage medium itself, it can only initiate a version request broadcast message to the intranet in the boot phase, and wait for a response, wherein the version request broadcast message includes a request.
- the version type name, the version identifier, and the like of the version file are parsed by the device that receives the message, and it is determined whether the diskless device needs a version that is consistent with itself.
- At least one device (server) in the network needs to determine its own resource usage, and determine whether its own version of the transmission capability can support the current version transmission. If yes, the device is available to the diskless device. Sending a version request response message for responding to the version request broadcast message; if the local resource usage rate has exceeded the threshold, or another device has applied for the version upgrade, the device rejects the upgrade message to the diskless device, and the client receives the message. Then continue to wait for a response from other devices.
- the client After receiving the version request response message, the client determines the device that obtains the version, and sends a version upgrade confirmation request to the device. After the two parties confirm the handshake message, the transmission channel is established, and the version transmission is performed.
- the process of the process version transmission may include: sending a version transmission request to the specified tftp server as the device of the tftp client, and sending the version to the tftp server, that is, reading the version file to be sent from the specified memory and sending the version; Accept and save in making memory.
- the client After the version transmission ends, the client performs verification processing on the version according to the version information in the previous version request response message and the version header of the passed version file, and the verification processing includes type check and length check, and the like. .
- the client verifies successfully, the version is normal, and the upgrade success message is returned to the server, and the running version file is started. If the client verification fails, the client abandons the upgrade, restarts the device, and re-initiates the version request process to the network. After receiving the upgrade success message, the server clears the local related data and continues the scheduling of other tasks. If the server end transmission ends, the client does not get a response, indicating that the client is abnormal or the verification fails. The server side clears the local related data and continues other scheduling. The recovery mechanism is performed by the client.
- the client device since the client device sends a version request broadcast message to the network after booting, the related devices in all domains may return a response, and there may be no response within a certain period of time. Therefore, the present invention Device selection is done in several ways:
- the client receives multiple version request response messages within a specified time, the first three messages are received, and then the server side (peer device) carried in the version request response message is selected to have the lowest resource utilization rate.
- the server side peer device carried in the version request response message is selected to have the lowest resource utilization rate.
- the client When the client receives only one version request response message within the specified time, the client unconditionally selects the device;
- the client When the client does not receive a version request response message within the specified time, indicating that all related devices are busy or do not satisfy the client condition, the client continues to broadcast the version request message after waiting for a certain time until it is obtained. Answer until.
- the device as a server may suddenly encounter a situation in which the user occupies a large-scale resource.
- the related process of the device as the server is set to a lower priority to ensure that other services are preferentially scheduled; secondly, a certain threshold determination is added, that is, When the resource usage of the server itself reaches a certain threshold, the server voluntarily gives up the transmission of the version file.
- the timeout mechanism once the client waits for a timeout, the client initiates a version request process in the network again.
- the breakpoint resume transmission is supported to save the startup time of the device.
- the abnormal timeout of the client may be borrowed.
- the system realizes the abnormal protection of the disk-free device network startup. That is to say, when the peer end (server side) fails during the version file transmission process, the local end (client) obtains a version file abnormality, and the count times out, the local end re-initiates the version request process on the intranet, where support is broken. Continue to transfer, in order to save the boot time of the diskless device.
- the present invention solves this problem by using a sink device that supports the access device version request procedure in the network, as shown in FIG.
- the aggregation device supports the version request process of the access device, implements the version upgrade process of the server, and ensures that the version file of the access device is saved locally. After the entire network is restarted, as long as a diskless device obtains the version file from the aggregation device, it will trigger the mutual version upgrade between the diskless devices, so that the entire network can be quickly started up.
- Introduction device refers to a device with a local storage medium, that is, a disk device. After the entire network is restarted, the disk device will obtain the version file boot device from its local storage medium, thus providing the entire network with a usable version file, which can trigger the version upgrade between the entire network device, and quickly start the entire network. .
- the invention reduces the cost of equipment production and increases the speed at which the equipment is started.
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Stored Programmes (AREA)
Description
基于 P2P的无盘设备的网络启动方法及系统 技术领域
本发明涉及无盘设备的版本管理和网络启动技术， 尤其涉及基于点对 点 （P2P, Peer-to-Peer ) 的无盘设备的网络启动方法及系统。 背景技术
目前， 常见的版本启动方式包括有盘设备启动和无盘设备启动。 其中， 有盘设备通过其自带的存储介质存储的版本文件完成设备的启动； 无盘设 备通过到指定的服务器索要版本， 通过网络传输到本地， 然后在本地运行 完成设备的启动。
这两种方式各有优缺点， 有盘设备启动具有不占用网络资源、 相对稳 定的优点， 但是， 每台设备都需要有自带的存储介质， 导致设备生产成本 相对较高。 无盘设备启动过程中， 版本读取与存储完全通过 RAM读写， 相 比 flash的读写， 大大的提高了版本读取与写入的速度， 缩短了版本升级的 时间， 但是， 需要所有内网设备开机后都到同一服务器索取版本， 会导致 网路拥塞以及服务器压力增大； 如果是多台设备并行， 会按队列进行， 导 致整体网络的启动速度受到影响， 尤其当服务器出现问题时， 会导致整个 网络设备瘫痪， 可靠性不高。
因此， 如何降低设备生产成本， 并使网络中的设备快速启动， 成为亟 待解决的问题。 发明内容
本发明的目的在于提供基于 P2P的无盘设备的网络启动方法及系统， 解决了网络中设备生产成本高和设备启动速度慢的问题。
根据本发明的一个方面， 本发明提供了一种基于 P2P的无盘设备的网 络启动方法， 所述方法包括：
网络中无盘设备启动过程中， 向网络中其他设备发送版本请求广播消 网络中至少一个设备响应所述版本请求广播消息， 向所述无盘设备发 送版本请求应答消息；
无盘设备根据接收的所述版本请求应答消息， 从做出所述响应的一个 设备中获取版本文件， 并利用所述版本文件完成启动。
优选的， 所述版本请求广播消息包括请求版本文件的版本类型名和版 本标识。
优选的， 所述网络中至少一个设备响应所述版本请求广播消息， 向所 述无盘设备发送版本请求应答消息， 包括：
网络中至少一个设备接收所述版本请求广播消息并解析， 得到版本类 型名和版本标识； 将所述版本类型名和所述版本标识与本地的版本信息进 行比较， 并在匹配时， 根据自身传输版本能力， 将包含本地的版本信息和 资源使用率的版本请求应答消息发送至所述无盘设备。
优选的， 所述无盘设备根据所述版本请求应答消息， 从做出所述响应 的一个设备中获取版本文件， 并利用所述版本文件完成启动， 包括：
无盘设备在预定时间内收到至少一条来自其它设备的版本请求应答消 息， 选取最先做出响应的三个设备；
根据版本请求应答消息， 向三个设备中资源使用率最低的设备发送版 息后， 从所述设备中获取版本文件；
利用所述版本文件， 完成无盘设备的启动。
优选的， 所述从做出所述响应的一个设备中获取版本文件之后， 所述
方法还包括版本校验步驟；
所述版本校验步驟包括： 无盘设备获取版本文件后， 将所述版本文件 的版本头和版本请求应答消息中的版本信息进行比较； 若匹配， 则启动所 述版本文件， 否则， 重新向网内其它设备请求版本文件。
优选的， 所述方法还包括： 若无盘设备获取版本文件超时， 则重新向 网内其它设备请求版本文件， 进行版本文件的断点续传。
优选的， 所述版本文件具有版本头， 所述版本头包括版本类型名、 版 本标识、 版本生成时间和版本大小。
优选的， 所述其它设备包括其它无盘设备和 /或本地带有存储介质的有 盘设备和 /或汇聚端设备。
优选的， 所述网络是接入网的一个内网。
根据本发明的另一个方面， 本发明还提供了一种基于 P2P的无盘设备 的网络启动系统， 所述系统包括：
无盘设备的版本请求模块， 用于在网络中无盘设备启动过程中， 向网 络中其他设备发送版本请求广播消息；
所述其他设备上的请求应答模块， 用于响应所述版本请求广播消息， 向所述无盘设备发送版本请求应答消息；
无盘设备的版本获取模块， 用于根据接收的所述版本请求应答消息， 从做出所述响应的一个设备中获取版本文件， 并利用所述版本文件完成启 动。
与现有技术相比， 本发明的有益效果在于： 本发明利用 P2P技术， 使 网络启动不再单一的依靠某一台或者几台设备， 平均了资源利用率， 减少 了特定网路压力， 增强了设备可靠性， 降低了设备生产成本， 提高了设备 启动速度。
附图说明
图 1是本发明基于 P2P的无盘设备的网络启动方法的实现流程图； 图 2是本发明提供的版本结构图；
图 3是本发明基于 P2P的无盘设备的网络启动流程图；
图 4是本发明第一实施例提供的基于 P2P的无盘设备的网络拓朴结构 图；
图 5是本发明第二实施例提供的基于 P2P的无盘设备的网络拓朴结构 图。 具体实施方式
以下结合附图对本发明的优选实施例进行详细说明， 应当理解， 以下 所说明的优选实施例仅用于说明和解释本发明， 并不用于限制本发明。
P2P技术是指点对点的网络传输。在整个网络中，没有服务器和客户端 的界限， 每台设备都是服务器， 每台也是客户端。 设备可以在网络中按需 寻找自己需要的资源， 根据特定规则选定服务器进行下载与传输。 本发明 提出一种基于 P2P的无盘设备的网络启动方法， 通过采用 P2P技术， 摒弃 了原有无盘设备启动过程中必须设置专门的服务器的方式， 使网内所有运 行相同版本文件的设备都可以为其它无盘设备提供相关的版本文件进行使 用， 同时自己也是客户端， 可以向其他设备索要自己需要的版本文件。
基于 P2P的无盘设备的网络特指为： 在接入网的某一内网， 所有运行 相同版本文件的无盘设备组成的网络。 网络中的所有设备的存活依赖于自 己周围同类型的设备， 当某一设备发生重启或者是异常断电等情况后， 该 设备重启过程中， 会向自己周围运行正常的设备索取版本运行启动。
如图 1所示， 本发明提供的基于 P2P的无盘设备的网络启动方法包括 如下步驟：
步驟 101 : 网络中无盘设备启动过程中， 向网络中其他设备发送版本请
求广播消息。
其中， 所述版本请求广播消息包括请求版本文件的版本类型名和版本 标识。
步驟 102: 网络中至少一个设备响应所述版本请求广播消息， 向所述无 盘设备发送版本请求应答消息。
所述步驟 102 包括： 网络中至少一个设备接收所述版本请求广播消息 并解析， 得到版本类型名和版本标识； 将所述版本类型名和版本标识与本 地的版本信息进行比较， 并在匹配时， 根据自身传输版本能力， 将包含本 地的版本信息和资源使用率的版本请求应答消息发送至所述无盘设备。
步驟 103: 无盘设备根据所述版本请求应答消息，从做出所述响应的一 个设备中获取版本文件， 并利用所述版本文件完成启动。
所述步驟 103 包括： 无盘设备在预定时间内收到至少一条来自其它设 备的版本请求应答消息， 选取最先做出响应的三个设备； 根据版本请求应 答消息， 向三个设备中资源使用率最低的设备发送版本升级确认请求， 并 获取版本文件； 利用所述版本文件， 完成无盘设备的启动。
所述步驟 103还包括： 无盘设备获取版本文件后， 将所述版本文件的 版本头和版本请求应答消息中的版本信息进行比较； 若匹配， 则启动所述 版本文件， 否则， 重新向内网其它设备请求版本文件。
进一步地， 若无盘设备获取版本文件超时， 则重新向网内其它设备请 求版本文件， 进行版本文件的断点续传。
上述版本文件具有版本头， 所述版本头包括版本类型名、 版本标识、 版本生成时间和版本大小。
上述其它设备包括其它无盘设备和 /或本地带有存储介质的有盘设备和 /或汇聚端设备。
相应的， 本发明还提供了一种基于 P2P的无盘设备的网络启动系统， 所述系统包括： 无盘设备的版本请求模块、 无盘设备的版本获取模块和除 所述无盘设备以外其他设备上的请求应答模块； 其中，
无盘设备的版本请求模块， 用于在网络中无盘设备启动过程中， 向网 络中其他设备发送版本请求广播消息；
所述其他设备上的请求应答模块， 用于响应所述版本请求广播消息， 向所述无盘设备发送版本请求应答消息；
无盘设备的版本获取模块， 用于根据接收的所述版本请求应答消息， 从做出所述响应的一个设备中获取版本文件， 并利用所述版本文件完成启 动。
上述网络是接入网的某一内网。
图 2显示了本发明提供的版本文件结构图。 如图 2所示， 本发明中设 备所用的版本文件需要有特定的版本文件标识， 即版本头。 所述版本头位 于二进制版本文件最前端， 通过版本头生成工具生成， 包括一些特定的标 识， 例如版本类型名 （标识设备类型）、 版本标识 （标识版本号）、 版本生 成时间、 版本大小等等。 这些标识在设备的版本升级过程中， 用于进行版 本校验和版本升级保护。 图 2 中仅描述了版本头存在情况， 由于基于不同 操作系统生成的版本文件的差别较大， 这里用二进制版本文件代替， 不再 针对某一产品细化。
所述版本文件通过网络传输到无盘设备后， 保存至无盘设备本地的特 定的内存内 （一般使用高端保留内存， 即高端内存）， 然后再从特定的内存 里将版本文件解压到版本运行的指定内存地址进行运行， 以启动设备。 需 要说明的是， 这里需要保留通过网络传输获取的版本文件， 以提供给其它 设备版本升级所用。
考虑到节省内存使用， 满足部分内存资源受限的设备， 版本文件解压
运行后， 高端内存中可以只保存版本片段， 实现分布式存储。
图 3显示了本发明基于 P2P的无盘设备的网络启动的具体流程图， 如 图 3所示， 将设备分为作为服务器端身份的设备和作为客户端身份的设备。
无盘设备作为客户端重启之后， 因为其本身没有存储介质， 所以只能 在启动（boot )阶段向内网发起版本请求广播报文， 并等待应答， 其中， 所 述版本请求广播消息中包括请求版本文件的版本类型名、 版本标识等字段， 以供接收到该报文的设备进行解析， 并判定所述无盘设备是否需要与自己 一致的版本。
网络中至少一个设备（服务器端）收到所述报文后， 首先需要判断自 身的资源使用情况， 判断自身的传输版本能力是否能够支持本次版本传输， 如果可以， 则向所述无盘设备发送用于响应版本请求广播报文的版本请求 应答消息； 如果本地资源使用率已超出门限， 或者已有其他设备申请版本 升级， 则向所述无盘设备发送拒绝升级消息， 客户端收到消息之后继续等 待其他设备的应答。
当客户端收到版本请求应答消息之后， 确定获取版本的设备， 并向该 设备发送版本升级确认请求， 经过双方确认握手消息后， 建立传输通道， 进行版本传输。 其中， 进程版本传输的过程可以包括： 作为 tftp客户端的设 备， 向指定 tftp服务器发送版本传输请求， tftp服务器端进行版本发送， 即 从指定内存读取需发送的版本文件并发送； 客户端进行版本接受并保存在 制定内存。 版本传输结束之后， 客户端会根据之前版本请求应答消息里面 的版本信息及传过来的版本文件的版本头， 对版本进行校验处理， 所述校 验处理包括类型校验和长度校验等等。 如果客户端校验成功， 说明版本正 常， 并向服务器端返回升级成功消息， 并启动运行版本文件。 如果客户端 校验失败， 客户端放弃本次升级， 重新启动设备， 并重新向网络发起版本 请求流程。
服务器端接收到升级成功消息后， 清除本地相关数据， 继续其他任务 的调度。 如果服务器端传输结束， 还没有得到客户端的应答， 说明客户端 异常或者校验失败， 服务器端一样清空本地相关数据， 继续其他调度。 恢 复机制由客户端进行。
进一步地， 上述步驟中， 由于客户端设备开机之后会在 boot下， 向网 络发送版本请求广播消息， 所有域内的相关设备都可能会返回应答， 也可 能一定时间内没有一条应答， 因此， 本发明通过采取以下几个方式进行设 备选择：
1、 当客户端在指定时间内收到多条版本请求应答消息时， 筛选最先收 到的三条消息， 然后选择所述版本请求应答消息中携带的服务器端 （对端 设备） 资源使用率最低的设备；
2、 当客户端在指定的时间内仅收到一条版本请求应答消息时， 客户端 无条件选择该设备；
3、 当客户端在指定的时间内没有收到一条版本请求应答消息时， 说明 所有相关设备都忙或者不满足客户端条件， 则客户端在等待特定的时间后 继续广播版本请求消息， 直到得到应答为止。
进一步地， 作为服务器的设备在给其他无盘设备进行版本文件传输过 程中， 会存在突然出现用户占用大规模资源的情况。 为解决这种情况下的 无盘设备网络启动的异常保护， 首先， 要将作为服务器的设备的相关进程 设置比较低的优先级， 以保证其他业务优先调度； 其次， 增加一定的门限 判定， 即当服务器本身资源使用率达到一定的门限时， 服务器主动放弃此 次版本文件的传输。 利用超时机制， 客户端一旦等待超时， 则重新在网内 发起版本请求流程， 这里支持断点续传， 以节省设备的启动时间。
进一步地， 作为服务器的设备在向其他无盘设备进行版本文件传输的 过程中， 出现死机或者异常重启等情况时， 可以借用客户端的异常超时机
制实现无盘设备网络启动的异常保护。 也就是说， 当对端 （服务器端）在 版本文件传输过程中失效时， 本端 （客户端）获取版本文件出现异常， 计 数超时， 则本端重新在内网发起版本请求流程， 这里支持断点续传， 以便 节省无盘设备的启动时间。
进一步地， 如果某地区因电路故障而出现区域性断电时， 整个域内的 网路需要全部重启， 那么会出现没有无盘设备有版本可用的情况。 因此， 本发明通过在网路中使用支持接入设备版本请求流程的汇聚端设备解决该 问题， 如图 4所示。 汇聚端设备支持接入设备的版本请求流程， 实现服务 器端的版本升级流程， 保证本地保存接入设备的版本文件。 当整个网络重 启之后， 只要有一台无盘设备从汇聚端设备上获取到了版本文件， 就会触 发无盘设备之间的相互的版本升级， 使整个网络快速启动起来。 当汇聚端 设备不支持接入设备的版本请求流程时， 还可以在内网下添加一个或者几 个 "引子" 设备， 如图 5 所示。 所谓 "引子" 设备是指本地带存储介质的 设备， 即有盘设备。 当整个网络重启之后， 有盘设备会从其本地存储介质 中获取版本文件启动设备， 这样就给整个网络提供了可使用的版本文件， 可触发整个网络设备之间的版本升级， 快速启动整个网络。
综上所述， 本发明降低了设备生产的成本， 提高了设备启动的速度。 尽管上文对本发明进行了详细说明， 但是本发明不限于此， 本技术领 域技术人员可以根据本发明的原理进行各种修改。 因此， 凡按照本发明原 理所做的修改， 都应当理解为落入本发明的保护范围。
Claims
1、 基于点对点 P2P的无盘设备的网络启动方法， 其特征在于， 所述方 法包括：
网络中无盘设备启动过程中， 向网络中其他设备发送版本请求广播消 网络中至少一个设备响应所述版本请求广播消息， 向所述无盘设备发 送版本请求应答消息；
无盘设备根据所述版本请求应答消息， 从做出所述响应的一个设备中 获取版本文件， 并利用所述版本文件完成启动。
2、 根据权利要求 1所述的方法， 其特征在于， 所述版本请求广播消息 包括请求版本文件的版本类型名和版本标识。
3、 根据权利要求 1所述的方法， 其特征在于， 所述网络中至少一个设 备响应所述版本请求广播消息， 向所述无盘设备发送版本请求应答消息， 包括： 网络中至少一个设备接收所述版本请求广播消息并解析， 得到版本 类型名和版本标识； 将所述版本类型名和所述版本标识与本地的版本信息 进行比较， 并在匹配时， 根据自身传输版本能力， 将包含本地的版本信息 和资源使用率的版本请求应答消息发送至所述无盘设备。
4、 根据权利要求 1所述的方法， 其特征在于， 所述无盘设备根据所述 版本请求应答消息， 从做出所述响应的一个设备中获取版本文件， 并利用 所述版本文件完成启动， 包括：
无盘设备在预定时间内收到至少一条来自其它设备的版本请求应答消 息， 选取最先做出响应的三个设备；
根据版本请求应答消息， 向三个设备中资源使用率最低的设备发送版 息后， 从所述设备中获取版本文件； 利用所述版本文件， 完成无盘设备的启动。
5、 根据权利要求 4所述的方法， 其特征在于， 所述从做出所述响应的 一个设备中获取版本文件之后， 所述方法还包括版本校验步驟；
所述版本校验步驟包括： 无盘设备获取版本文件后， 将所述版本文件 的版本头和版本请求应答消息中的版本信息进行比较； 若匹配， 则启动所 述版本文件， 否则， 重新向网内其它设备请求版本文件。
6、 根据权利要求 1所述的方法， 其特征在于， 所述方法还包括： 若无盘设备获取版本文件超时， 则重新向网内其它设备请求版本文件， 进行版本文件的断点续传。
7、 根据权利要求 6所述的方法， 其特征在于， 所述版本文件具有版本 头， 所述版本头包括版本类型名、 版本标识、 版本生成时间和版本大小。
8、 根据权利要求 1至 7任一项所述的方法， 其特征在于， 所述其它设 备包括其它无盘设备和 /或本地带有存储介质的有盘设备和 /或汇聚端设备。
9、 根据权利要求 1至 7任一项所述的方法， 其特征在于， 所述网络是 接入网的一个内网。
10、 一种基于 P2P的无盘设备的网络启动系统， 其特征在于， 所述系 统包括：
无盘设备的版本请求模块， 用于在网络中无盘设备启动过程中， 向网 络中其他设备发送版本请求广播消息；
所述其他设备上的请求应答模块， 用于响应所述版本请求广播消息， 向所述无盘设备发送版本请求应答消息；
无盘设备的版本获取模块， 用于接收并根据所述版本请求应答消息， 从做出所述响应的一个设备中获取版本文件， 并利用所述版本文件完成启 动。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201110256509.9 | 2011-09-01 | ||
| CN2011102565099A CN102970312A (zh) | 2011-09-01 | 2011-09-01 | 基于p2p的无盘设备的网络启动方法及系统 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2012155645A1 true WO2012155645A1 (zh) | 2012-11-22 |
Family
ID=47176246
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/CN2012/072566 WO2012155645A1 (zh) | 2011-09-01 | 2012-03-19 | 基于p2p的无盘设备的网络启动方法及系统 |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN102970312A (zh) |
| WO (1) | WO2012155645A1 (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2019023976A1 (zh) * | 2017-08-02 | 2019-02-07 | 福建联迪商用设备有限公司 | 一种业务数据处理方法、客户端、服务端及系统 |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP6369024B2 (ja) * | 2014-01-09 | 2018-08-08 | 富士通株式会社 | 映像配信システム及び映像配信システムにおいて使用されるノード装置 |
| CN110290206B (zh) * | 2019-06-26 | 2021-12-03 | 万物共算(成都)科技有限责任公司 | 一种用于网吧环境的分布式计算系统及方法 |
| CN110557673A (zh) * | 2019-09-18 | 2019-12-10 | 深圳市友华软件科技有限公司 | 家用网络终端的磁盘共享方法 |
| CN113900721A (zh) * | 2021-10-15 | 2022-01-07 | 北京字节跳动网络技术有限公司 | 操作系统启动方法、装置和电子设备 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1956380A (zh) * | 2006-10-19 | 2007-05-02 | 华为技术有限公司 | 系统软件获取方法和系统 |
| CN101192952A (zh) * | 2006-11-30 | 2008-06-04 | 中国科学院声学研究所 | 一种广域协同工作系统部署方法 |
| CN102118421A (zh) * | 2010-01-05 | 2011-07-06 | 中兴通讯股份有限公司 | 对等网络及对等节点重新启动的方法 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101127961B (zh) * | 2007-09-19 | 2011-05-11 | 中兴通讯股份有限公司 | 电子业务指南的差异性更新系统及其方法 |
-
2011
- 2011-09-01 CN CN2011102565099A patent/CN102970312A/zh active Pending
-
2012
- 2012-03-19 WO PCT/CN2012/072566 patent/WO2012155645A1/zh active Application Filing
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1956380A (zh) * | 2006-10-19 | 2007-05-02 | 华为技术有限公司 | 系统软件获取方法和系统 |
| CN101192952A (zh) * | 2006-11-30 | 2008-06-04 | 中国科学院声学研究所 | 一种广域协同工作系统部署方法 |
| CN102118421A (zh) * | 2010-01-05 | 2011-07-06 | 中兴通讯股份有限公司 | 对等网络及对等节点重新启动的方法 |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2019023976A1 (zh) * | 2017-08-02 | 2019-02-07 | 福建联迪商用设备有限公司 | 一种业务数据处理方法、客户端、服务端及系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN102970312A (zh) | 2013-03-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11307787B2 (en) | Technologies for providing manifest-based asset representation | |
| JP5951071B2 (ja) | プル・モード及びプッシュ・モードを組み合わせるシステム及び方法 | |
| KR101457241B1 (ko) | 네트워크에서의 완전 메시 레이트 트랜잭션 | |
| KR101227121B1 (ko) | 피어 투 피어 콘텐츠 배포 네트워크를 이용한 비디오 서비스 지연 다운로딩 | |
| US9392081B2 (en) | Method and device for sending requests | |
| WO2012155645A1 (zh) | 基于p2p的无盘设备的网络启动方法及系统 | |
| CN110505275A (zh) | 数据传输方法、系统、服务器及计算机可读存储介质 | |
| US11251981B2 (en) | Communication method and apparatus | |
| WO2009039745A1 (fr) | Procédé, appareil et système de traitement de données | |
| JP2008017446A (ja) | デバイス装置および接続制御方法 | |
| WO2013155935A1 (zh) | 一种焊接电源与计算机之间进行数据通信的方法 | |
| CN105262836A (zh) | 服务器推送信息的方法及客户端接收推送信息的方法 | |
| CN111327650A (zh) | 数据传输方法、装置、设备及存储介质 | |
| WO2013189069A1 (zh) | 负荷分担方法及装置、单板 | |
| CN109947081B (zh) | 网联车辆控制方法及装置 | |
| CN112491951B (zh) | 对等网络中的请求处理方法、服务器及存储介质 | |
| JP2004266610A (ja) | 通信システム、リモートアクセスサーバ装置とリソース管理方法およびプログラム | |
| CN116938712A (zh) | 设备升级方法、设备升级装置以及计算机可读存储介质 | |
| WO2011009362A1 (zh) | 下载数据的方法、装置和系统及节点 | |
| CN114553936B (zh) | 连接方法、装置、电子设备和计算机可读存储介质 | |
| WO2015180560A1 (zh) | 一种对业务路由报文进行处理的方法和业务节点 | |
| WO2022116767A1 (zh) | 数据传输方法、用户设备及存储介质 | |
| WO2022110919A1 (zh) | 一种信息订阅的方法及装置 | |
| CN111935651B (zh) | 一种集群业务实现方法、装置、介质、基站及系统 | |
| WO2014194526A1 (zh) | 移动网络数据资源获取方法、设备及系统 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 12785649 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 12785649 Country of ref document: EP Kind code of ref document: A1 |