我有一个Windows应用程序,它利用第三方工具(FaxMan)通过连接到PC的COM端口发送传真.为了对我的应用程序进行压力测试,我想创建一些假装附加传真调制解调器的虚拟COM端口.然后我想"欺骗"发送传真,而不是实际发送任何东西.虚拟COM端口需要响应标准AT命令,就像发送传真一样.欺骗失败的能力将是一个额外的好处.
我的第一个想法是使用虚拟COM端口驱动程序重定向到telnet或其他TCP会话 - 然后我可以有一个假装通过传真动作的TCP服务器.但是,我很乐意为一个组件付费.
我在这个问题上工作了好几年,开发了一种局域网传真产品.我怀疑你能做得好.
开发一个虚拟COM驱动程序意味着开发一个内核驱动程序(除非你可以买一个现成的):这是可行的(我做了),但我猜它比它的价值要麻烦得多(如果值得,我会感到惊讶)你的时间).
另一个问题是,有各种传真调制解调器和传真调制解调器标准(你说你希望模仿一个足以愚弄FaxMan).
另一个(基本)问题是更简单(非纠错)的传真协议是(硬)实时协议:传真调制解调器上有一些(或多或少)缓冲,但连接到传真调制解调器的PC在接收时发送或超限时无法承受欠载...这意味着通过telnet(使用TCP定时器和缓冲区)重定向此流量要么在最坏的情况下中断传真会话(FaxMan将超时)或者最多意味着您的测试不能代表真实世界(非仿真)的性能.
无论如何,你还想尝试压力测试:你的应用程序,还是第三方FaxMan？
我建议最便宜的解决方案和最现实的测试将使用真正的硬件:真正的COM端口,真正的传真调制解调器和真实的(或可能是模拟的)电话线.
编辑以回答迈克尔答案中的评论中的问题
假设数据的传输是一个小问题(例如,因为你可以简单地连接两个串口),编写模拟传真调制解调器的软件是一个小问题吗？
它可能很小:如果您的负载测试仅仅是"将传真数据发送到比特桶",那么您的模拟调制解调器通常只需要对看起来像AT命令的每个/任何内容做出"OK"响应,以及各种其他响应.特定于传真的AT + F_whatever_命令.但这是一个非常低保真,而不是非常严格的测试.
这很简单 - 但传真数据传输中是否涉及某些协议？或者协议只是AT命令集的变体,并且欺骗"OK"就是它的全部内容吗？老实说,我不知道,但我认为会有一些更复杂的协议.
电话协议的名称如"T.4"和"T.30".PC-to-faxmodem协议通常是称为"1类传真"或"2类传真"的协议.后者("2级"或"2.0级")是两者中的较高级别:更多的ASCII和更少的二进制数据,不那么对时间敏感(类1对10秒的msec iirc敏感),因为它封装/包含更多基础T.30谈判而不是第1类; 它由扩展的AT命令(即AT + F_something_命令及其响应)以及二进制编码的传真图像数据的转储组成.
一些响应不仅仅是"OK"(即它们代表可用/协商的传真会话参数),但是(在第2类而不是第1类)它们是ASCII编码而不是二进制,因此实际上并不太难.
必须有某种握手,对吧？否则,普通的旧传真机在加载新页面时可能会丢失一堆数据.
是的,在页面之间(即每页之前)有一些握手("我现在可以发送吗？" ).没有测试时间的负载测试仿真只会响应"是的,继续(我只是将数据倾销到位桶中,无需查看它,所以我在乎什么)"握手询问.
仿真还必须看二值图像数据(它从PC获得)的
我不知道可以在FaxMan应用程序中构建什么计时器(无论您是否需要在模拟响应中添加人为延迟,以防止FaxMan意识到响应异常快):可能不是,但可能.
页面内可能有也可能没有任何握手:
对于较旧的传真机/传真协议,没有:相反,设备在页面之前协商"传真会话参数",包括波特率:它们协商两端都能够支持的同步波特率.那(同步处理整页数据的能力)是为什么它是一个硬实时协议的一部分.
较新的传真机/传真协议支持每页内的"纠错":页面以较小(但仍然是同步)的块发送:每个块都被确认,或者NAK和重新传输.
京公网安备 11010802040832号 | 京ICP备19059560号-6 
