现象：通讯服务器在收到数据后，过1分钟又会收到重复的数据，后来的这条重复数据与之前的数据唯一不同的地方在于最前面多了个问号。
分析及解决：怀疑是板子软件的问题，但最终测试的结果表明板子并没有给dtu发送重复的数据，难道是dtu自己会重复发数据？问四信的技术人员，说让我设置dtu的调试信息级别为2，观察下情况，设置后，观察dtu反馈的调试信息，发现在发送完正确的数据后，过1分钟dtu确实会发送一个包，但这个包是心跳包，而服务器却把这个心跳包和上次收到的数据连接到一起当成了新收到的数据包。
继续调试服务器端的测试程序，发现确实是这样的，我用tcp工具模拟板子给通讯服务器发了一个数据，然后又发了一个心跳包，果然，问题重现了--服务器果然把这个心跳包和上次收到的数据连接到一起当成了新收到的数据包。
但是奇怪的是我用其他单个字符试了下却没有出现这个问题，而用四信的心跳包（0xfe）试时，才出现这个问题。
也不继续深究了，只要确认是这个问题就行。
继续研究我的通讯服务器，发现我并没有在接收数据前把接收缓冲区清零，但是即便我清零（实际上并没有真正清零，而只是增加了一个表示字符串结束的0）也没起作用还是老问题。
因此，我改进了程序，增加了一个收到数据长度的变量iBufferValidLength，
然后调用的地方变成这样了：
string sContent = System.Text.Encoding.Default.GetString(myAsyncEventArgs._state.Buffer, 0, myAsyncEventArgs._state.iBufferValidLength);
而之前出现问题时的调用是这样的
string sContent = System.Text.Encoding.Default.GetString(myAsyncEventArgs._state.Buffer);
问题搞定了，但是，依然需要反思：出现问题后，先不要着急去解决，而是要清理思路，想一想有可能在哪个环节出问题，尤其像这种从上到下一条线的系统，好几个点都是有可能出问题的，常常，问题很简单，但却被我们想复杂了