rogerwfrech / nmodbus

Automatically exported from code.google.com/p/nmodbus
0 stars 0 forks source link

ModbusIpTransport no call of StreamResource.DiscardInBuffer before StreamResource.Write #73

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
I use NModbus library to poll PLC on Mikrotik Wi-Fi link. Sometimes I get in 
strange behaviour: my program send modbus TCP request with transaction id (00 
13, for example), but fail to read data and report no connection. That's ok. 
Next I send new request with incremented transaction id (00 14), but get 
response to previous request.
To investigate this problem I used dumpcap+Wireshark. See additional 
information part.

What is the expected output? What do you see instead?
Usual algorithm (as in ModbusSerialTransport class):
1. flush read buffer;
2. write data;
3. read data.

In ModbusIpTransport class I can only see step 2 & step 3.

What version of the product are you using? On what operating system?
NModbus_net-3.5_1.11.0.0
Windows Server 2008 R2 Standard x64

Please provide any additional information below.
I attached 2 files:
1. log.txt - log from my application
2. network_log.pcapng - network log 
From network log you can see that actually I get response from PLC, but after 
read timeout. So response data for previous response is in read buffer. When 
next request is send library reads this data and fail to validate it.

Original issue reported on code.google.com by Bask...@gmail.com on 28 Jul 2014 at 6:36

Attachments:

GoogleCodeExporter commented 9 years ago
I examined the source code once again: TcpClientAdapter class implements 
DiscardInBuffer method and even calls NetworkStream.Flush but it has no affect 
on network streams (MSDN). So my original issue has no sense...

But I still can't solve my problem. Is seems I just read previous data from 
stream. Am I missing something?

Original comment by Bask...@gmail.com on 31 Jul 2014 at 12:19