导致.NET SerialPort类DataReceived事件触发的原因是什么？

Question

我从MSDN文档中了解到事件DataReceived不一定每个字节触发一次。

但是有谁知道导致事件发生的机制究竟是什么？

在事件触发之前，每个字节的接收是否会重新启动一个必须达到的定时器，比如字节之间的10 ms？

我问，因为我正在尝试编写一个应用程序来读取来自串口的XML数据。

因为我的笔记本电脑没有串口，所以我使用虚拟串口仿真器。 （我知道，我知道 - 我对ATM无能为力。）

当我通过模拟端口将数据传递到我的应用程序时，事件会为每个XML记录触发一次（大约1500字节）。完善。但是当另一个办公室的同事尝试使用实际电缆连接的两台计算机时，DataReceived事件会在每10个字节的XML之后重复触发，这会完全抛弃应用程序。

Answer 1

DataReceived可以在一个或多个字节准备好读取的任何时候触发。它何时被触发取决于操作系统和驱动程序，并且在接收的数据和在.NET中触发的事件之间也会有一个小的延迟。

您不应该依赖DataReceived事件的时间来控制流程。

相反，解析底层协议，如果您还没有收到完整的消息，请等待更多。如果您收到多条消息，请确保保留左侧消息，因为它们将是下一条消息的开头。

Answer 2

Mark Byers指出，这取决于操作系统和驱动程序。在最低级别，标准的RS232芯片（在我的生命中，我不记得每个人都复制以制作'标准'的那个）将在其入站寄存器中有数据时触发中断。驱动程序的“底端”必须获取该数据（可能是芯片缓冲区大小的任何数量），并将其存储在驱动程序的缓冲区中，并向操作系统发出信号，告知它有数据。在这一点上，.NET框架可以开始发现数据是可用的。根据操作系统发出打开串口的应用程序的信号（这是一个操作系统级别的操作，并提供从.NET框架到操作系统/驱动程序级别实现的'真实'链接），可能确实存在任何数据量＆GT;缓冲区中有1个字节，因为驱动程序的底端可能在此期间加载了更多数据。我敢打赌，在你的系统上，驱动程序提供了一个巨大的缓冲区，并且只在数据流中出现重大暂停后发出信号。另一方面，你的同事的系统更频繁地发出信号。 Mark Byer再次提出解析协议的建议。我已经在TCP套接字上实现了一个类似的系统，处理这种情况的唯一方法是缓冲数据，直到你得到完整的协议消息，然后将完整的消息传递给应用程序。