具体实施方式
本发明提出的一种通过无线局域网远程启动透明计算系统客户端的方法,结合附图及实施例详细说明如下:
本发明方法基于由客户端、服务器及无线网络组成的透明计算系统,客户端可以是笔记本电脑、PDA、手机等支持无线通信的计算设备,服务器可以是普通PC或者服务器,客户端和服务器之间通过无线网络连接。无线网络的接入点(Access Point,AP)可以是无线路由器或者服务器上的无线网卡。服务器存储着客户端对应的操作系统,客户端本身不预置任何操作系统,而是利用客户端上设置的引导芯片(ROM或者EPROM),通过无线网络从服务器获取相应操作系统来实现远程启动。
本发明提出的通过无线局域网远程启动透明计算系统客户端的方法是:客户端利用引导芯片通过无线网络进行远程启动。该方法流程如图1所示,包括以下步骤:
步骤(1):客户端加电,执行引导芯片中的引导代码,根据预先设置的搜索周期搜索当前区域内的透明网络,若在预定时间内搜索到透明网络,获得透明网络的信号强度、透明网络支持的操作系统的个数、透明网络支持的所有操作系统最近一次远程启动的平均带宽,转步骤(2),否则终止搜索,远程启动失败;
本步骤的具体实施方式包括以下步骤:
步骤(1.1):客户端执行引导芯片ROM或者EPROM中的引导代码,检查代码自身的合法性和完整性,驱动无线网卡,准备搜索无线网络;
步骤(1.2):客户端开始计时;
步骤(1.3):客户端在网络搜索请求消息的厂商自定义信息域中填入透明计算系统标识后,广播该网络搜索请求消息;
步骤(1.4):透明网络AP收到网络搜索请求消息后,检查厂商自定义信息域,如果不是透明计算系统客户端的请求,则将其丢弃;如果是透明计算系统客户端的请求,则在网络搜索应答消息的厂商自定义域中填入该AP所在的透明网络的透明网络信息,向客户端返回网络搜索应答消息;
所说的透明网络信息的内容举例如表1所示,该表中包括的内容如下(括号中为该项内容的长度):
1)透明计算系统标识(4字节);
2)透明网络的ID(32字节);
3)该透明网络支持的操作系统的个数(2字节);
4)该透明网络支持的所有操作系统最近一次远程启动的平均带宽(8字节);
5)支持的每一个操作系统的ID(2字节);
6)支持的每一个操作系统后续数据的长度(1字节);
7)支持的每一个操作系统的名称(1~50字节);
8)支持的每一个操作系统最近一次远程启动的带宽(8字节);
表1透明网络信息的内容
| 名称 |
长度(字节) |
| 透明计算系统标识 |
4 |
| 透明网络的ID |
32 |
| 网络支持的操作系统个数 |
2 |
| 网络支持的所有操作系统最近一次远程启动的平均带宽 |
8 |
| 第一个操作系统的ID |
2 |
| 第一个操作系统后续数据的长度 |
1 |
| 第一个操作系统的名称 |
1~50 |
| 第一个操作系统最近一次远程启动的带宽 |
8 |
| ...... |
|
| 第N个操作系统的ID |
2 |
| 第N个操作系统后续数据的长度 |
1 |
| 第N个操作系统的名称 |
1~50 |
| 第N个操作系统最近一次远程启动的带宽 |
8 |
步骤(1.5):客户端收到网络搜索应答消息后,通过厂商自定义信息域验证该消息是否为透明网络AP返回的消息;如果该消息不是透明网络AP返回的消息,则将其丢弃;如果该消息是透明网络AP返回的消息,则记录该透明网络的ID、该透明网络支持的操作系统的个数、该透明网络支持的所有操作系统最近一次远程启动的平均带宽以及该透明网络的信号强度(透明网络的信号强度是客户端无线网卡根据收到的无线信号电磁波的振幅的大小得到的);
步骤(1.6):每次到达搜索周期(搜索周期一般范围为1s~5s),则客户端判断当前搜索到的网络是否同时满足以下条件:
1)至少搜索到一个透明网络;
2)连续两次搜索周期搜索到的透明网络的结果相同;
如果满足,则搜索过程结束,转到步骤(2);否则客户端计时清零,重新计时,转到步骤(1.3);
步骤(1.7):若计时到达预定时间(一般范围为10s~30s)时没有搜索到任何透明网络,则终止搜索;客户端提示用户当前区域搜索不到任何透明网络,不能提供透明计算服务,客户端远程启动失败;
步骤(2):客户端将搜索到的透明网络依据透明网络的信号强度、透明网络支持的操作系统的个数、透明网络支持的所有操作系统最近一次远程启动的平均带宽进行排序,将排序后得到的透明网络列表显示给用户;
该步骤具体实施方式包括以下步骤(假设步骤(1)搜索到的透明网络的个数为N,N为正整数,N个透明网络分别表示为W1,W2,...,WN):
步骤(2.1):依据信号强度由强到弱对N个透明网络进行排序,排序后W1,W2,...,WN的排名依次表示为R1,1,R1,2,...,R1,N;
步骤(2.2):依据支持的操作系统的个数由多到少对N个透明网络进行排序,排序后W1,W2,...,WN的排名依次表示为R2,1,R2,2,...,R2,N;
步骤(2.3):依据支持的所有操作系统最近一次远程启动的平均带宽由高到低对N个透明网络进行排序,排序后W1,W2,...,WN的排名依次表示为R3,1,R3,2,...,R3,N;
步骤(2.4):定义三项排名对应的加权系数分别为α、β、γ(α>0,β>0,γ>0,α+β+γ=1),计算W1,W2,...,WN各自的总排名系数Rt,1,Rt,2,...,Rt,N:
Rt,i=α*R1,1+β*R2,i+γ*R3,i(i=1,2,...,N);
步骤(2.5):依据Rt,i由小到大对N个透明网络进行排序,将排序后得到的透明网络列表显示给用户;
步骤(3):用户选择远程启动使用的透明网络,客户端对用户选择的透明网络进行网络身份验证,若验证成功,则转步骤(4);否则转步骤(3);该步骤具体实施方式包括以下步骤:
步骤(3.1):用户选择透明网络;
步骤(3.2):客户端在网络验证请求消息的厂商自定义信息域中填入透明计算系统标识,向用户选择的透明网络的AP发送网络验证请求消息;
步骤(3.3):透明网络AP收到网络验证请求消息后,检查消息中的厂商自定义信息域以判断该消息是否为透明计算系统客户端的请求消息;如果不是透明计算系统客户端的请求消息,则直接将该网络验证请求消息丢弃;如果是透明计算系统客户端的请求消息,则提取消息中的验证信息,在网络验证应答消息的厂商自定义信息域中填入透明计算系统标识,向客户端返回网络验证应答消息;
步骤(3.4):客户端收到网络验证应答消息后,通过厂商自定义信息域验证该消息是否为透明网络AP返回的消息;如果该消息不是透明网络AP返回的消息,则将其丢弃;如果该消息是透明网络AP返回的消息,则从消息中提取验证结果,将验证结果显示给用户;若验证成功,则转入步骤(4);若验证失败,则转入步骤(3.1),提示用户重新选择透明网络;
上述的步骤(3.2)和步骤(3.3)构成了网络验证请求消息和网络验证应答消息的一次交互过程;根据使用的验证协议的不同,网络验证请求消息和网络验证应答消息交互的次数有所不同;对于某些协议,可能存在着多次交互过程;
步骤(4):客户端对用户选择的并验证成功的透明网络进行测试,若透明网络满足客户端远程启动的需求,则转步骤(5),否则转回步骤(3);
本步骤防止用户选择的透明网络由于网络带宽过低、网络延时过大而不能有效支持客户端远程启动的需求,本步骤具体实施方式步骤如图2所示,包括:
步骤(4.1):客户端提示用户选择测试使用的参数类型,包括自定义参数和系统默认参数两种;如果用户选择自定义参数,则转入步骤(4.2);如果用户选择系统默认参数,则转入步骤(4.3);
步骤(4.2):客户端提示用户依次输入以下四个测试参数:要测试的操作系统的ID、测试持续的时间、测试允许的最低平均带宽和允许的最大平均延时;用户输入完毕后,将四个测试参数设置为用户输入值,转入步骤(4.4);
步骤(4.3):将测试参数设置为系统默认参数,包括:要测试的操作系统的ID、测试持续的时间(一般范围为10s~30s)、测试允许的最低平均带宽(一般范围为100Kbps~1Mbps)和允许的最大平均延时(一般范围为10ms~100ms);
步骤(4.4):客户端向服务器发送测试开始请求消息;消息中包含有步骤(4.2)或步骤(4.3)中设置的测试参数:测试的操作系统ID、测试持续的时间、允许的最低平均带宽和允许的最大平均延时;
步骤(4.5):服务器收到测试开始请求消息后,返回测试开始应答消息;测试开始应答消息中包含有客户端将要发出的第一个读写请求信息;读写请求信息包括如下内容:
1)操作类型:读请求/写请求;
2)起始位置:读写请求操作的磁盘的起始位置;
3)操作长度:读或写的数据长度;
步骤(4.6):客户端收到测试开始应答消息后,提取出其中的读写请求信息,据此将第一个读写请求消息发送给服务器;同时开始计时;
步骤(4.7):服务器收到读写请求消息后,返回读写应答消息;读写应答消息中包含了客户端下一次的读写请求信息;
步骤(4.8):客户端收到读写应答消息后,提取出其中的读写请求信息,向服务器发送下一次读写请求消息;
在上述的步骤(4.5)和步骤(4.7)中,服务器每次按如下方式确定客户端下一次的读写请求信息:
1)在客户端远程启动某操作系统过程中,服务器记录下客户端的每一个读写请求,依次存入启动过程读写日志;
2)在1)之后,当有客户端请求测试与1)中相同的操作系统时,从相应的启动过程读写日志的第一条记录开始依次读取下一条记录,作为客户端的下一次读写请求;
步骤(4.9):判断测试是否结束:当计时到达指定的测试持续的时间时,客户端停止发送读写请求消息,并向服务器发送测试结束请求消息;否则转步骤(4.8);
步骤(4.10):服务器收到测试结束请求消息后,返回测试结束应答消息;
步骤(4.11):客户端收到测试结束应答消息后,向服务器发送测试结果请求消息;测试结果请求消息包括本次测试的操作系统ID、平均带宽、平均延时三项信息;
步骤(4.12):服务器收到测试结果请求消息后,记录测试结果,返回测试结果应答消息;
步骤(4.13):客户端收到测试结果应答消息后,判断测试结果是否满足远程启动要求,即是否同时满足以下条件:
1)测试结果中的平均带宽不低于允许的最低平均带宽;
2)测试结果中的平均延时不高于允许的最大平均延时;
如果满足,则转到步骤(5);否则转到步骤(3.1),用户重新选择透明网络;
步骤(5):引导芯片的启动代码从服务器获得该客户端的标识;
步骤(6):客户端从服务器下载一个脚本解释程序并加载运行;
步骤(7):在上述脚本解释程序运行的环境下,通过对语言脚本的解释执行,让用户选择需要加载的操作系统;
步骤(8):客户端从服务器下载操作系统内核镜像并加载运行,服务器记录客户端的每一个读写请求,存入启动过程读写日志,以备以后有客户端进行同一操作系统测试时使用(在上述的步骤(4.5)和步骤(4.7)中,正是读取了启动过程读写日志中的信息)。
(上述步骤(1)~步骤(4)为本发明的区别特征的处理步骤,步骤(5)~步骤(7)为透明计算系统现有的远程启动方法的处理步骤,步骤(8)为本发明基于透明计算系统现有远程启动方法修改的步骤。)
本发明适用于支持Wi-Fi、ZigBee、Bluetooth等无线通信的各类透明计算客户端设备,如笔记本电脑、PDA、手机等。无线网络的AP可以是无线路由器或者服务器的无线网卡。下面以PC为客户端、Wi-Fi为无线网络、服务器的无线网卡为AP作为优选实施例来进行详细说明。
本方法的实施例涉及到的设备包括:远程启动客户端、远程启动服务器和AP。远程启动客户端硬件结构和一般PC相同,但是没有本地硬盘,并在主板上设置了一块用于通过Wi-Fi网络远程启动操作系统的引导芯片(采用ROM或者EPROM)。服务器采用一般的PC或者服务器即可,其上安装有远程启动服务。AP使用远程启动服务器上的无线网卡,只服务于透明网络。
本实施例采用的设备配置如下:
客户端:Intel Celeron M 353 634MHz CPU、Intel i915GMS芯片组、DDR2 667MHz512MB内存、Atheros AR5007EG 54Mbps无线网卡。
服务器:Intel Core 2Duo T7200 2.0GHz CPU、Intel i945PM芯片组、DDR2 667MHz2.0GB内存、HITACHI 120GB 5400RPM硬盘、Intel(R)PRO/Wireless 3945ABG 54Mbps无线网卡。
本实施例中客户端远程启动的流程如图1所示,具体包括以下步骤:
步骤(1):客户端加电,执行引导芯片中的引导代码,根据预先设置的搜索周期搜索当前区域内的透明网络,若在预定时间内搜索到透明网络,获得透明网络的信号强度、透明网络支持的操作系统的个数、透明网络支持的所有操作系统最近一次远程启动的平均带宽转步骤(2),否则终止搜索,远程启动失败。
根据IEEE 802.11标准,Wi-Fi网络的搜索包括主动搜索和被动搜索两种:
(a)主动搜索:搜索请求节点向网络广播Probe Request消息,AP收到ProbeRequest消息后会回应Probe Response消息。搜索请求节点利用收到的ProbeResponse消息获知网络信息。
(b)被动搜索:AP会周期性地广播Beacon消息来传播网络信息,搜索请求节点通过监听Beacon消息来获知网络信息。
上述的Probe Request消息用来探测当前区域的Wi-Fi网络,Probe Response则是AP返回给搜索请求方的消息。Probe Request消息的格式如表2所示,包括要探测的SSID、该网络支持的传输速率、厂商自定义信息等信息单元。Probe Response消息的格式如表2所示,包括消息发送时刻发送端的时间、加入到本网络的设备需要满足的功能要求等信息。Beacon消息的格式与Probe Response类似,这里不做说明。
表2Probe Request消息格式
| 序号 |
信息单元 |
描述 |
| 1 |
SSID |
要探测的网络的SSID(值为0时探测所有网络) |
| 2 |
Supported Rates |
支持的传输速率 |
| 3 |
Request Information |
指示Probe Response中要包含的信息 |
| 4 |
Extended SupportedRates |
除了Supported Rates之外的其它支持的传输速率 |
| Last |
Vendor Specific |
厂商自定义信息 |
表3Probe Response消息格式
| 序号 |
信息单元 |
描述 |
| 1 |
Timestamp |
消息发送时刻发送端的时间 |
| 2 |
Beacon Interval |
相邻两次Beacon消息之间的时间差 |
| 3 |
Capability |
指示加入到本网络的设备需要满足的功能要求 |
| 4 |
Service Set Identifier(SSID) |
网络标识 |
| 5 |
Supported Rates |
网络支持的传输速率 |
| 6-22 |
省略 |
省略 |
| Last-I |
Vendor Specific |
厂商自定义信息 |
| Last-n |
Requested Information |
对应Probe Request中请求的信息 |
为了只让透明计算客户端搜索到透明网络,而一般设备无法搜索到透明网络,本实施例的AP只支持主动搜索。即:本实施例的AP监听Probe Request消息,并返回ProbeResponse消息;但不主动广播Beacon消息。
透明网络搜索的具体过程如下:
步骤(1.1):客户端执行ROM或者EPROM中的引导代码,检查代码自身的合法性和完整性,驱动Wi-Fi网卡,准备搜索Wi-Fi网络。
步骤(1.2):客户端开始计时。
步骤(1.3):客户端组装Probe Request消息,在Probe Request消息的VendorSpecific信息单元中填入透明计算信息。Vendor Specific信息单元的格式如表4所示。其中,Vendor-specific Content中填入透明网络信息,透明网络信息的格式如表1所示,包含的字段有:
1)透明计算系统标识(4字节);
2)透明网络的ID(32字节);
3)该透明网络支持的操作系统的个数(2字节);
4)该透明网络支持的所有操作系统最近一次远程启动的平均带宽(8字节);
5)支持的每一个操作系统的ID(2字节);
6)支持的每一个操作系统后续数据的长度(1字节);
7)支持的每一个操作系统的名称(1~50字节);
8)支持的每一个操作系统最近一次远程启动的带宽(8字节)。
在Probe Request消息中,“透明计算系统标识”字段填入“54:72:61:6e”,其它字段置零。
表4Vendor Specific信息单元格式
| 域 |
长度(字节) |
描述 |
| Element ID |
1 |
信息单元的ID |
| Length |
1 |
信息内容的长度(后面两项长度之和) |
| OUI |
3 |
厂商标识 |
| Vendor-specificContent |
0~252 |
信息内容 |
步骤(1.4):透明网络AP收到Probe Request消息后,检查消息中的VendorSpecific信息单元是否包含“透明计算系统标识”(54:72:61:6e),以判断该请求是否来自透明计算客户端。如果不是透明计算客户端的请求,则将其丢弃;如果是透明计算客户端的请求,则组装Probe Response消息,在Probe Response消息中Vendor Specific域的Vendor-specific Content填入该网络的透明网络信息。其中,“透明计算系统标识”字段填入“54:72:61:6e”,“透明网络的ID”字段填入该透明网络的SSID,接下来的字段则按表1所示格式分别填入该网络支持的操作系统信息,包括:该透明网络支持的操作系统的个数、该透明网络支持的所有操作系统最近一次远程启动的平均带宽、各操作系统的ID、名称、最近一次远程启动的带宽。透明网络信息填写完毕后,将Probe Response消息返回给客户端。
步骤(1.5):客户端收到Probe Response消息后,检查消息中是否包含“透明计算系统标识”(54:72:61:6e)以判断该网络是否为透明网络。对于非透明网络的消息,直接丢弃;对于透明网络的消息,客户端记录相应的网络信息,包括该透明网络的ID、该透明网络支持的操作系统的个数、该透明网络支持的所有操作系统最近一次远程启动的平均带宽、该透明网络的信号强度。透明网络的ID、支持的操作系统的个数以及支持的所有操作系统最近一次远程启动的平均带宽是从Probe Response消息的Vendor Specific单元的Vendor-specific Content得到的。透明网络的信号强度得到的方式为:Wi-Fi网卡收到消息时,会在消息前面加上一个扩展头,该扩展头包含有网络信号强度信息(无线网卡根据收到的无线信号电磁波的振幅的大小得到网络信号强度);通过提取扩展头包含的网络信号强度信息,客户端可获知该网络的信号强度。
步骤(1.6):每次到达搜索周期(默认值为2s),则客户端判断当前搜索到的网络是否同时满足以下条件:
1)至少搜索到一个透明网络;
2)连续两次搜索周期搜索到的透明网络的结果相同。
如果满足,则搜索过程结束,转到步骤(2);否则客户端计时清零,重新计时,转到步骤(1.3)。
步骤(1.7):若计时到达预定时间(默认值为15s)时没有搜索到任何透明网络,则终止搜索。客户端提示用户当前区域搜索不到任何透明网络,不能提供透明计算服务,客户端远程启动失败。
步骤(2):客户端将搜索到的透明网络依据透明网络的信号强度、透明网络支持的操作系统的个数、透明网络支持的所有操作系统最近一次远程启动的平均带宽进行排序,将排序后得到的透明网络列表显示给用户。本步骤的具体过程如下(假设步骤(1)搜索到的透明网络的个数为N,N为正整数,N个透明网络分别表示为W1,W2,...,WN):
步骤(2.1):依据信号强度由强到弱对N个透明网络进行排序,排序后W1,W2,...,WN的排名依次表示为R1,1,R1,2,...,R1,N。
步骤(2.2):依据支持的操作系统的个数由多到少对N个透明网络进行排序,排序后W1,W2,...,WN的排名依次表示为R2,1,R2,2,...,R2,N。
步骤(2.3):依据支持的所有操作系统最近一次远程启动的平均带宽由高到低对N个透明网络进行排序,排序后W1,W2,...,WN的排名依次表示为R3,1,R3,2,...,R3,N。
步骤(2.4):定义三项排名对应的加权系数分别为α、β、γ(α>0,β>0,γ>0,α+β+γ=1),计算W1,W2,...,WN各自的总排名系数Rt,1,Rt,2,...,Rt,N:
Rt,i=α*R1,i+β*R2,i+γ*R3,i(i=1,2,...,N);
本实施例中α、β、γ的取值分别为0.3,0.4,0.3。
步骤(2.5):依据Rt,i由小到大对N个透明网络进行排序,将排序后得到的透明网络列表显示给用户。
步骤(3):用户选择远程启动使用的透明网络,客户端对用户选择的透明网络进行网络身份验证,若验证成功,则转步骤(4);否则转步骤(3)。
步骤(2)将透明网络列表显示给用户后,用户从透明网络列表中选择远程启动要使用的透明网络,输入密钥,之后客户端依据IEEE 802.11标准完成网络身份验证。根据IEEE802.11标准,网络身份验证使用Authentication消息。Authentication消息的格式如表5所示。实施例的客户端在Authentication消息的Vendor Specific信息单元中填入了透明计算信息。透明网络AP只对包含透明计算信息的请求提供验证服务,而忽略其它验证请求消息。
具体验证过程如下:
步骤(3.1):用户选择远程启动使用的透明网络。
步骤(3.2):客户端依照Authentication消息的格式组装网络验证请求消息,在消息中的Vendor Specific信息单元中填入透明网络信息。透明网络信息的格式如表1所示。与Probe Request消息一样,该透明网络信息中“透明计算系统标识”字段填入“54:72:61:6e”,其它字段置零。
步骤(3.3):透明网络AP收到网络验证请求消息后,验证消息中的Vendor Specific信息单元是否包含“透明计算系统标识”(54:72:61:6e),以判断该请求是否来自透明计算系统客户端。如果不是透明计算系统客户端的消息,则直接将该网络验证请求消息丢弃;如果是透明计算系统客户端的请求消息,则提取消息中的验证信息,处理后依照Authentication消息的格式组装网络验证应答消息,在网络验证应答消息中的VendorSpecific信息单元中填入透明网络信息;透明网络信息中“透明计算系统标识”字段填入“54:72:61:6e”,其它字段置零;透明网络信息填写完毕后将该网络验证应答消息返回给客户端。
步骤(3.4):客户端收到网络验证应答消息后,检查消息中的Vendor Specific信息单元是否包含“透明计算系统标识”(54:72:61:6e),以判断该网络是否为透明网络。对于非透明网络的消息,直接丢弃;对于透明网络的消息,从消息中提取验证结果,将验证结果显示给用户。若验证成功,则转入步骤(4);若验证失败,则转入步骤(3.1),提示用户重新选择透明网络。
上述的步骤(3.2)和步骤(3.3)构成了网络验证请求消息和网络验证应答消息的一次交互过程。根据使用的验证协议的不同,网络验证请求消息和网络验证应答消息交互的次数有所不同。对于某些协议,可能存在着多次交互过程。
表5Authentication消息格式
| 序号 |
信息单元 |
描述 |
| 1 |
Authentication Algorithm Number |
标识不同的验证协议 |
| 2 |
Authentication Transaction SequenceNumber |
描述当前所处的验证阶段 |
| 3 |
Status Code |
指示验证是否成功 |
| 4 |
Challenge Text |
网络验证过程中使用的挑战文本 |
| 序号 |
信息单元 |
描述 |
| Last |
Vendor Specific |
厂商自定义信息 |
步骤(4):客户端对用户选择的并验证成功的透明网络进行测试,若透明网络满足客户端远程启动的需求,则转步骤(5),否则转回步骤(3)。
本步骤防止用户选择的透明网络由于网络带宽过低、网络延时过大而不能有效支持客户端远程启动的需求,具体步骤如图2所示,包括:
步骤(4.1):客户端提示用户选择测试使用的参数类型,包括自定义参数和系统默认参数两种;如果用户选择自定义参数,则转入步骤(4.2);如果用户选择系统默认参数,则转入步骤(4.3)。
步骤(4.2):客户端提示用户依次输入以下四个测试参数:要测试的操作系统的ID、测试持续的时间、测试允许的最低平均带宽和允许的最大平均延时;用户输入完毕后,将四个测试参数设置为用户输入值,转入步骤(4.4)。
步骤(4.3):将测试参数设置为系统默认参数,包括:要测试的操作系统的ID(该网络支持的第一个操作系统的ID)、测试持续的时间(15s)、测试允许的最低平均带宽(300Kbps)和允许的最大平均延时(10ms)。
步骤(4.4):客户端向服务器发送测试开始请求消息,该消息格式如表6所示,消息中包含有步骤(4.2)或步骤(4.3)设置的测试参数:测试的操作系统ID、测试持续的时间、允许的最低平均带宽和允许的最大平均延时。
表6测试开始请求消息
| 域 |
长度(字节) |
描述 |
| Type |
1 |
消息类型(值为1) |
| OSID |
2 |
测试的操作系统的ID |
| Duration |
2 |
测试持续的时间(单位:s) |
| MinThroughput |
8 |
允许的最低平均带宽(单位:bit/s) |
| MaxDelay |
2 |
允许的最大平均延时(单位:ms) |
步骤(4.5):服务器收到测试开始请求消息后,记录客户端的请求信息,返回测试开始应答消息,格式如表7所示。测试开始应答消息中包含有客户端将要发出的第一个读写请求信息,读写请求信息包括:
1)操作类型:读请求/写请求;
2)起始位置:读写请求操作的磁盘的起始位置;
3)操作长度:读或写的数据长度。
测试开始应答消息中的第一次操作类型(NextOptType)、起始位置(NextOffset)和操作长度(NextSize)是从服务器的启动过程读写日志得到的,后文将对此进行描述。
表7测试开始应答消息
| 域 |
长度(字节) |
描述 |
| Type |
1 |
消息类型(值为2) |
| OSID |
2 |
要测试的操作系统的ID |
| Duration |
2 |
测试持续的时间(单位:s) |
| MinThroughput |
8 |
允许的最低平均带宽(单位:bit/s) |
| MaxDelay |
2 |
允许的最大平均延时(单位:ms) |
| NextOptType |
1 |
第一次操作类型(值为1时为写请求,为0时为读请求) |
| NextOffset |
8 |
第一次读写请求操作的磁盘的起始位置 |
| NextSize |
2 |
第一次读或写的数据长度 |
步骤(4.6):客户端收到测试开始应答消息后,向服务器发送读写请求消息,开始计时。读写请求消息的格式如表8所示。第一次读写请求消息的操作类型、起始位置、操作长度由服务器返回的测试开始应答消息得到。对于写请求,按照Size的取值将Data域对应长度置零。
表8读写请求消息格式
| 域 |
长度(字节) |
描述 |
| Type |
1 |
消息类型(值为3) |
| OSID |
2 |
测试的操作系统的ID |
| TimeStamp |
8 |
消息发送时刻客户端的时间 |
| OptType |
1 |
操作类型(值为1时为写请求,为0时为读请求) |
| Offset |
8 |
读写请求操作的磁盘的起始位置 |
| Size |
2 |
读或写的数据长度 |
| 域 |
长度(字节) |
描述 |
| Data |
0~1482 |
写请求时才有此项 |
步骤(4.7):服务器收到客户端的读写请求消息后,向客户端返回读写应答消息。读写应答消息的格式如表9所示。与测试开始应答消息一样,读写应答消息中的下一次操作类型(NextOptType)、下一次起始位置(NextOffset)和下一次操作长度(NextSize)是从服务器的启动过程读写日志得到的,后文将对此进行描述。对于读请求,按照Size的取值将Data域对应长度置零。
表9读写应答消息
| 域 |
长度(字节) |
描述 |
| Type |
1 |
消息类型(值为4) |
| OSID |
2 |
要测试的操作系统的ID |
| OptType |
1 |
本次操作类型(值为1时为写请求,为0时为读请求) |
| Offset |
8 |
本次读写请求操作的磁盘的起始位置 |
| Size |
2 |
本次读写的数据长度 |
| NextOptType |
1 |
下一次操作类型(值为1时为写请求,为0时为读请求) |
| NextOffset |
8 |
下一次读写请求操作的磁盘的起始位置 |
| NextSize |
2 |
下一次读或写的数据长度 |
| Data |
0~1482 |
读请求的应答消息才有此项 |
步骤(4.8):客户端收到服务器的读写应答消息后,提取消息中的读写信息(OptType、Offset、Size),如果该读写信息与客户端最近一次发出的读写请求消息不同,则忽略该读写应答消息,否则提取读写应答消息中的NextOptType、NextOffset、NextSize作为下一次的读写信息,填入读写请求消息,发往服务器。对于写请求,按照Size的取值将Data域对应长度置零。
为了统计测试结果,实施例定义了三个变量来记录测试数据:使用变量TotalSize记录当前成功读写的总数据量,使用TotalDelay记录当前读写请求的总延时,使用TotalRequests记录读写请求的总个数,上述三个变量的初始值均为0。
客户端在接收每个读写应答消息时,获取读写应答消息中的Size值,按如下方式更新三个变量:
TotalSize=TotalSize+Size;
TotalDelay=TotalDelay+(当前时间-TimeStamp);
TotalRequests=TotalRequests+1;
上式中的TimeStamp是客户端发送对应于该读写应答消息的读写请求消息时客户端的时间(见表8中的TimeStamp项)。
在上述的步骤(4.5)和步骤(4.7)中,服务器每次按如下方式确定客户端下一次的读写请求信息:
1)在客户端远程启动某操作系统过程中,服务器记录下客户端的每一个读写请求,依次存入启动过程读写日志,表10是一段启动过程读写日志的示例。
2)在1)之后,当有客户端请求测试与1)中相同的操作系统时,从相应的启动过程读写日志的第一条记录开始依次读取下一条记录,作为客户端的下一次读写请求。步骤(4.5)中第一次操作类型(NextOptType)、起始位置(NextOffset)和操作长度(NextSize)对应启动过程读写日志的第一行记录。步骤(4.7)中的每次确定下一次操作类型(NextOptType)、下一次起始位置(NextOffset)和下一次操作长度(NextSize)则是从启动过程读写日志的第二行记录开始依次读取的。
3)如果客户端请求测试的操作系统之前没有被远程启动过,则服务器随机产生客户端下一次读写请求消息。随机产生的分布原则如下:
(a)操作类型:读请求、写请求各占50%;
(b)起始位置:读写的起始位置在磁盘范围内平均分布;
(c)操作长度:读写数据的长度均为1KB。
表10启动过程读写日志
| 序号 |
操作类型 |
起始位置(字节) |
操作长度(字节) |
| 1 |
读 |
8510485762 |
572 |
| 2 |
写 |
2469852352 |
1242 |
| 3 |
写 |
1323741824 |
748 |
| ... |
|
|
|
步骤(4.9):判断测试是否结束:当计时到达指定的测试持续的时间时,客户端停止发送读写请求消息,同时,客户端向服务器发送测试结束请求消息;否则转步骤(4.8)。
表11测试结束请求消息
| 域 |
长度(字节) |
描述 |
| Type |
1 |
消息类型(值为5) |
| OSID |
2 |
测试的操作系统的ID |
步骤(4.10):服务器收到客户端的测试结束请求消息后,向客户端发送测试结束应答消息。测试结束应答消息的格式如表12所示。
表12测试结束应答消息
| 域 |
长度(字节) |
描述 |
| Type |
1 |
消息类型(值为6) |
| OSID |
2 |
测试的操作系统的ID |
步骤(4.11):客户端收到服务器测试结束应答消息后,统计测试数据,向服务器发送测试结果请求消息。测试结果请求消息的格式如表13所示。
表13测试结果请求消息
| 域 |
长度(字节) |
描述 |
| Type |
1 |
消息类型(值为7) |
| OSID |
2 |
测试的操作系统的ID |
| AvgThroughput |
8 |
本次测试的平均带宽 |
| AvgDelay |
2 |
本次测试的平均延时 |
测试结果消息中的AvgThroughput指的是测试过程中客户端的平均网络带宽、AvgDelay指的是客户端每个读写请求消息的平均延时,结合步骤(4.8)中的三个变量:TotalSize、TotalDelay、TotalRequests,通过如下方式计算获得:
AvgThroughput=TotalSize/Duration;
AvgDelay=TotalDelay/TotalRequests;
(上式中的Duration是测试持续的时间,见表6。)
步骤(4.12):服务器收到客户端的测试结果请求消息后,向客户端发送测试结果应答消息。测试结果应答消息的格式如表14所示。
表14测试结果应答消息
| 域 |
长度(字节) |
描述 |
| Type |
1 |
消息类型(值为8) |
| OSID |
2 |
测试的操作系统的ID |
| AvgThroughput |
8 |
本次测试的平均带宽 |
| AvgDelay |
2 |
本次测试的平均延时 |
步骤(4.13):客户端收到测试结果应答消息后,判断测试结果是否满足远程启动要求,即是否同时满足以下条件:
1)测试结果中的平均带宽不低于允许的最低平均带宽(AvgThroughput>=MinThroughput);
2)测试结果中的平均延时不高于允许的最大平均延时(AvgDelay<=MaxDelay)。
如果满足,则转到步骤(5);否则转到步骤(3.1),用户重新选择透明网络。
步骤(5):引导芯片的启动代码从服务器获得该客户端的标识。
步骤(6):客户端从服务器下载一个脚本解释程序并加载运行。
步骤(7):在上述脚本解释程序运行的环境下,通过对语言脚本的解释执行,让用户选择需要加载的操作系统。
步骤(8):客户端从服务器下载操作系统内核镜像并加载运行。在下载过程中,服务器会记录客户端的每一个读写请求,作为启动过程读写日志,以备以后有客户端进行同一操作系统测试时使用。表10是一段启动过程读写日志的示例。在上述的步骤(4.5)和步骤(4.7)中,正是读取了启动过程读写日志中的信息。在下载过程中,服务器还会记录客户端启动过程中的带宽,记录包含的内容如表15所示。在下载完毕后,依据启动过程中的带宽来计算该服务器支持的所有操作系统远程启动的平均带宽(综合之前已经有的其它操作系统的启动带宽记录)。在网络搜索阶段透明网络AP(服务器的无线网卡)发送的ProbeResponse消息中的Vendor-specific Content中的“支持的每一个操作系统最近一次远程启动的带宽”、“支持的所有操作系统最近一次远程启动的平均带宽”就是由此得到的。启动过程读写日志和启动带宽记录可以存储在MySQL、Oracle等数据库中,也可以以文件形式存储。本实施例存储在文本文件中。
表15启动带宽记录
| 名称 |
描述 |
| OSID |
操作系统ID |
| OSName |
操作系统名称 |
| SSID |
网络标识 |
| ClientID |
客户端标识 |
| Throughput |
启动过程的带宽 |
至此,本实施例的所有实施步骤都已经进行了详细的说明。本发明并不限于上述实施例,本领域技术人员在不脱离本发明实质性思想的基础上进行各种修改和改进后得到的技术方案,均视为在本发明的范围之内。本发明适用的范围以权利要求书为准进行确定。