基于WPF实现的回音壁网络程序

LittleGirl

发布日期: 2020-05-11 15:02:37 浏览量: 133
评分:
star star star star star star star star star star
*转载请注明来自write-bug.com

一、术语与约定

缩写、术语 解 释
Socket Windows套接字库文件及相关函数
TCP 传输控制协议,一种面向连接的传输层协议
UDP 用户数据报协议,一种无连接的传输层协议
GUI 图形用户界面
CUI 命令行用户界面
WPF Windows Presentation Foundation,一套基于XML、.NET Framework、矢量绘图技术的展示层开发框架。

二、功能模块设计概述

2.1 基本需求

  • 测试两个节点之间的通信延时;

  • 延时计算要求精确到毫秒级;

  • 多次(不少于10次,每次测试不少于30个样本点数据)测试,完成延时变化图表和统计平均延时,以及分析延时变化特点;

  • 测试与某台指定计算机之间的延时;

  • 测试数据存放在日志文件中;

  • 设计不少于三种不同的测试场景,如从距离的角度,从计算机是否忙于本地其它工作的角度(如播放视频),从计算机是否忙于其他下载的角度;

  • 另外编写程序或使用工具软件分析测试数据,如计算均值、方差、作图等;

  • 软件具有图形化界面,或者有命令行式菜单,可连续测试,可调整测试参数,如一次测试需要多个样本点;

2.2 功能概述

  • 能够测量客户端程序与服务器程序之间的通信延时;

  • 能够动态接收用户参数,调整测试方式;

  • 能够计算统计信息,生成相关图表;

2.3 主要技术指标

  • 测量通信延时的精确度;

  • 客户端程序的易用性;

2.4 关键问题分析及解决思路

2.4.1 消除主机处理时间与ARP对延时的影响

通过大部分服务器本身自带的“回音壁”服务器辅助,即通过 简单TCP/IP服务 中的 ECHO(端口7)进行,通过测量远程服务器的回传时间,使得主机处理时间与ARP殉职时间。

2.4.2 测量传输延时与主机距离的关系

通过多线程机制,自动搜索各个网段上的回音壁服务器,测量延时和通过Traceroute计算跳数。

2.4.3 自动生成Excel图表

本机安装Microsoft Office 2013后,通过调用Excel的COM接口,将测试数据动态转换为Excel 图表。

2.5 软件模块划分与层次结构关系

2.6 工作原理

2.7 各子模块方案设计

2.7.1 服务器部分

网络回传模块

采用TCP和/或UDP协议侦听指定端口,收到请求后自动建立连接。对于TCP协议采用逐字节回传策略,每从客户端接收一个字节便回送该字节,以减小本地处理延时;对于UDP协议采用逐数据报回传策略。

状态控制模块

根据用户的操作,能够实时响应用户的开启或关闭服务器请求。

2.7.2 客户端部分

网络通信模块

采用TCP和/或UDP协议,通过用户输入的IP地址和端口号,(连接目的端点并)向目的端点发送测试消息,记录(连接目的端点和)发送消息的时刻值,等待并接收回送消息。若收到回送消息,记录接收消息的时刻值,若没有接收到消息,记录错误信息。

进程控制模块

维护线程池和任务队列,控制后台线程的运行与停止。线程池用于在自动探测模式下按照特定规则生成IP地址队列,利用线程池对上述IP地址端口7进行测试。

图形交互模块

接收用户输入参数,显示实时信息。

图表输出模块

根据测试数据,调用Excel的COM接口,生成相应的Excel图表。

三、接口设计

3.1 外部接口关系

软件使用了Office 2013的COM接口(https://msdn.microsoft.com/zh-cn/library/office/microsoft.office.interop.excel.aspx ),其详细接口信息可以写一本书,此处从略。

3.2 内部接口关系

ExcelBuilder接口,在用户交互模块中调用。

四、模块详细设计

4.1 报文格式及定义

使用TCP及UDP协议的标准报文格式。

4.2 协议描述

使用Socket库文件中封装的TCP及UDP协议。

4.3 子模块设计

ExcelBuilder,用于Excel动态图表的构造,由于构造Excel图表本身是较为独立的功能,与具体的数据内容无关,故构建为独立项目。

五、界面展示

输入校验

同时作为服务器和客户端

同时启用TCP和UDP(C/S均可)

同时打开多个测试窗口

获取路由跳数并记录

实时信息显示(每秒刷新)

指定消息长度

域名解析

自动导出到Excel

六、问题及解决方案

6.1 获取路由跳数并记录

为什么要把 traceroute 的结果实时显示在界面上而不只是后台记录?

本题其实只是一个常识问题,如果没有该命令的使用经验可能无法直接猜到答案。traceroute(*nix 为 tracert)程序由于本身的运行机制原因,一次从调用到最终到达目标节点可能要超过 5 分钟甚至 10 分钟。若放在后台运行不利于用户获取当前的运行状况,甚至误以为测试已经结束或程序出现死循环从而一直占用 CPU 。用户的交互永远都是客户端最重要的部分之一。

6.2 非阻塞的阻塞

  1. // 后台线程中
  2. for (int i = 0; i < len; i++)
  3. {
  4. socket.Send(sth);
  5. socket.Receive(sth);
  6. // 回调UI线程
  7. window.Dispatcher.BeginInvoke(sth);
  8. }

采用了非阻塞的后台线程处理(所有代码及逻辑均正确),但为什么使用 localhost 测试时主线程依然完全阻塞?

回调请求 频率 太高(100微秒级),致使 UI 线程不足以在自己的时间片内完成更新图表任务,不断积压回调请求,导致 UI 线程阻塞。

6.3 危险的循环

  1. while (true)
  2. {
  3. socket.BeginAccept(callback);
  4. }

BeginAccept为非阻塞版本的接受连接请求,其中 callback 为接受连接后的回调,这种方式可能(这里是一定)会导致什么非预期后果?

内存泄漏。BeginAccept为 非阻塞 代码,调用后会在后台建立一个 状态机 以实现状态转移。由于非阻塞,循环会一直执行下去不会停止,而每次调用后消耗的资源不会被释放(除非建立连接的频率比循环快),最终导致内存泄漏。(本例中内存使用量达到 1.6GB,随后出现 OutOfMemory 异常)

6.4 搭错线

  1. for (int i = 0; i < count; i++)
  2. {
  3. socket.Send(sth);
  4. socket.Receive(sth);
  5. }

不考虑未给出部分,仅考虑“在循环的每一轮中调用一次 Send 和一次 Receive 并记录延时”这个逻辑本身有何漏洞?

一次 recv 的数据不一定是一次 send 的数据:由于客户机和服务器均为一次 send 对一次 recv,故不存在多次发送一次接收的问题;但一次发送的数据可能无法一次到达,故一次 recv 的内容可能只是一次 send 的内容的一部分,并且下次 recv 时收到的可能是上次未收完的剩余数据,导致时间记录错乱。

测试临界值:TCP(1368),UDP(1472)。

解决方案:

  • 根据发送数据长度while循环(需要增加额外逻辑)

  • 限制用户发送大数据(本项目采用)

6.5 若出现丢包,简单循环将被阻塞

  1. for (int i = 0; i < count; i++)
  2. {
  3. socket.Send(sth);
  4. socket.Receive(sth);
  5. }

如何应对可能出现的 UDP 丢包情况?

UDP不保证可靠性,可能在中途丢包,若直接放弃该数据点,接着后面的测试,则万一一定时间后该数据包 返回 ,则引起计时错乱。

  • 使用额外的应用层协议,比如增加序号(需要增加额外逻辑)

  • 等待一个足够长的时间后继续进行(需要增加额外耗时)

  • 切换到另一个端口后继续进行(需要增加额外逻辑)

  • 放弃后面的测试数据点(本项目采用)

上传的附件 cloud_download 基于WPF实现的回音壁网络程序.7z ( 5.07mb, 1次下载 )
error_outline 下载需要16点积分

发送私信

我是自己的太阳,无需仰仗谁的光芒

14
文章数
31
评论数
最近文章
eject