Windows中的虚拟COM端口-传真仿真器

我在这个问题上工作了几年,开发了一个局域网传真产品。我怀疑你能做好。

开发一个虚拟的COM驱动程序意味着开发一个内核驱动程序(除非你可以购买一个现成的):这是可行的(我做到了),但我想这比它的价值要麻烦得多(如果值得你花点时间的话,我会感到惊讶)。

另一个问题是有各种各样的传真调制解调器和传真调制解调器标准(你说你希望能很好地模仿一个来愚弄Faxman)。

另一个(基本的)问题是,更简单(非纠错)的传真协议是(硬的) 实时性 协议:传真调制解调器上有一些(或多或少)缓冲区,但是连接到传真调制解调器的PC在发送时不能运行不足,在接收时不能溢出…这意味着通过telnet重定向此流量(使用TCP计时器和缓冲区)或者最坏情况下中断传真会话(faxman将超时),或者最坏情况下意味着测试无法代表实际(非模拟)性能。

你到底在尝试什么压力测试:你的应用程序,还是第三方faxman?

我建议最便宜的解决方案和最现实的测试将使用真正的硬件:真正的COM端口、真正的传真调制解调器和真正的(或者可能是模拟的)电话线。

编辑以回答迈克尔回答中的问题。

假设数据传输是一个小问题(例如,因为您可以简单地将两个串行端口背靠背连接),那么编写模拟传真调制解调器的软件是一个小问题吗?

它可能很小:如果您的负载测试仅仅是“将传真数据发送到位桶”,那么您的模拟调制解调器通常只需要对看起来像at命令的每一个/任何东西响应“确定”,再加上对各种特定于at+f_的传真的各种其他响应,无论什么_u命令。但这是一个相当低的保真度,而不是非常严格的测试。

这很简单,但是传真数据传输中没有什么协议吗?或者该协议只是at命令集的一个变体,并且欺骗了一个“OK”,这就是它的全部内容吗?我真的不知道,但我认为会有一个更复杂的协议。

电话协议的名称类似于“T.4”和“T.30”。PC-to-Faxmodem协议通常是一种称为“1类传真”或“2类传真”的协议。后者(“Class 2”或“Class 2.0”)是二者的较高级别:更多的ASCII数据和更少的二进制数据,对时间不太敏感(Class 1对MSEC IIRC的10s敏感),因为它比Class 1封装/包装了更多的底层T.30协商;它由扩展的AT命令(即AT+F ou something ouu命令及其响应)组成。加上二进制编码的传真图像数据的转储。

有些响应不仅仅是“OK”(即它们代表可用/协商的传真会话参数),而是(在类2而不是类1中)它们是ASCII编码的,而不是二进制的,因此实际上并不太困难。

一定要握手,对吧?否则,一台普通的旧传真机在加载新页面时可能会丢失大量数据。

是的,有一些握手(“我现在可以发送吗?”) 之间 页面(即每页之前)。一个没有测试时间的负载测试仿真只会对握手查询做出响应:“是的,继续(我只会在不看数据的情况下将数据转储到位桶中,所以我关心什么)”。

仿真还必须观察二进制图像数据(它从PC获取的数据),以便 <DLE><ETX> 和 <DLE><DLE> ,以便在PC结束时响应OK,将图像数据转储到调制解调器。

我不知道faxman应用程序中可能内置了什么计时器(无论您是否需要在模拟响应中添加人工延迟,以防止faxman发现响应异常快速):也许没有,但可能。

页面内可能有或没有任何握手:

• 对于较旧的传真机/传真协议,没有:相反,设备在页面前协商“传真会话参数”,包括波特率:它们协商两端都能支持的同步波特率。这(同步处理整页数据的能力)是为什么它是一个困难的实时协议的一部分。
• 新的传真机/传真协议支持在每个页面内进行“纠错”:页面以较小的(但仍然是同步的)块发送:每个块都被确认,或者是裸块和重传。

我认为 ChrisW's advice 声音-尤其是电话线模拟器-它们不太贵,而且在我做调制解调器驱动程序时非常有用。

也就是说,有一个开源驱动程序包(根据他们的声明)允许您设置成对的虚拟COM端口: http://com0com.sourceforge.net/

您可以将faxman应用程序连接到一个COM端口,然后连接到一个处理at命令集的传真“模拟器”,以及您要测试的传真协议中的任何内容。这听起来像是你在找的-但是…

1. 我不知道Com0com驱动程序有多好用-我从来没有下载过它们,更不用说尝试过(我不确定我是否应该发布这个答案…)
2. 我不知道写一个传真模拟会涉及多少工作;我想这不是一个小任务。

虚拟调制解调器: http://www.eltima.com/products/virtual-modem-pro/