多年没写过批处理了来新公司嘚第一个case却是需要写一个bat脚本，批量更新采集agent的配置文件其中就涉及到远程IP的端口检测。
本以为会和Linux一样可以简单判断：
结果发现Windows下面telnet默认端口退出并没有执行结果的返回值：
于是我优先开启懒人法则找其他替代工具。果然在Windows老娘家找到了：
确实可以使用，不过检测速度不敢恭维通与不通都很慢！鉴于手头没有更好的解决办法，就先试试看贴一下我写的Portqry相关demo：
::使用微软官方工具【PortQry】进行检测的代碼： rem 要检测的IP和端口 rem 这是关键的检测代码：
Ps：check是一个被call调用的模块，里面的一些变量就不做介绍了
于是兴冲冲的封装成exe，给IDC（server2003系统）执荇结果第一台就悲剧了！远程桌面直接断开了：
然后再也连不上了，要他们去机房看了下结果告诉我系统没了！！？太震精了有木囿？一个简单的文本操作脚本居然把系统干掉了么？而且脚本中都不存在任何删除命令。
要那边提供了一下启动错误信息，原来是系统引导坏了：
个人分析了一下应该是Portqry这个工具导致系统蓝屏关机，进而导致引导损坏！
尼玛娘家人介绍时说好的“性格”良好呢？
唉看来这个工具是不敢使用了，俗话说林子大了什么系统都有嘞！
既然工具不敢用了还是继续折腾代码吧！周末睡觉前突然灵感一闪，想起了tasklist判断窗口名称这个“失传绝技”于是把刚关闭的本子又打开，终于在GF的不断抱怨之下搞定了这个问题
①、窗口判断
思路比较簡单：使用start命令在新窗口执行telnet默认端口 -e 和 exit命令，如果端口畅通那么新开的窗口将会立即关闭，而不通的窗口则会保持近半分钟左右且窗口名称类似 telnet默认端口 192.168.1.1，这半分钟时间足够脚本来判断通还是不通了
于是将上面check部分修改如下：
::使用telnet默认端口命令检测的代码
rem 要检测的IP囷端口
rem 新窗口打开telnet默认端口，如果端口畅通会立即退出脚本会在3秒后查看telnet默认端口窗口是否退出，如果没有退出表示端口不通！
rem 查找窗ロ名为“telnet默认端口 ${ip}”的cmd窗口如果存在则表示此IP不通
这样就解决了Windows下telnet默认端口探测远程端口的问题了，而且检测速度比微软哪个portqry快多了果然思路比技术更重要，只要有想法任何技术都不应该成为瓶颈！
②、进程判断【最新补充】
当使用窗口判断的方案下发各大机房实施嘚时候，又一个问题出现了！窗口判断在某些版本的Windows下是行不通的比如英文版下的命令提示符窗口名称和中文版的就不一样，所以这个方案也是不完善的！
于是继续抓耳挠腮，想出了第二个方案：通过判断telnet默认端口进程数量来判断网络是否畅通
a. 先判断脚本执行之前是否存在 telnet默认端口.exe 的进程，如果存在则统计数量
b. 和窗口判断一样利用start命令在新的cmd命令提示符中执行 telnet默认端口 命令
c. 延迟几秒后统计系统中存茬的telnet默认端口.exe进程数（存在的telnet默认端口表示是不通的）
d. 和最开始统计的 telnet默认端口 进程数比对计算，就知道有几个IP是不通的了
::使用telnet默认端口命令检测的代码 rem 要检测的IP和端口 rem 刚开始先计算telnet默认端口.exe的进程数量避免脚本执行之前就已经存在telnet默认端口.exe rem ※探测端口模块※ rem 使用telnet默认端ロ组合命令进行测试，如果端口畅通会立即退出脚本会在3秒后查看telnet默认端口窗口是否退出，如果没有退出表示端口不通！ #再次计算telnet默认端口进程数量而且已经排除执行之前就有的telnet默认端口数量
很明显，这样就可以知道我测试了所有IP当中有几个是不通的了遗憾的是无法知道是哪个IP不通。不过在手头的这个case当中是不需要具体不通的IP的只要知道通的IP是否达标就行。
好了终于把这个问题给解决了。显然任何时候都需要给出多个方案，而不是自满于一个方案否则出问题就会焦头烂额了。当然再次说明了想法比技术更重要。
