TCP/IP reliability?
TCP/IP reliability?
We designed a device using MOD5234 send out real-time data to PC. TCP/IP protocol is used for the data transfer. PC requests data from the device at the frequency of 4 times per second. Most of the time, TCP/IP communication is OK and data could be transferred correctly. But sometimes, MOD5234 will not response PC's request and the data package lost. Is there any way to make a reliable TCP/IP communication between MOD5234 & PC? Thanks!
Re: TCP/IP reliability?
It should be reliable. Use Wireshark to determine where the problem is. My first guess would be that the protocol and tcp/ip stack are fine. The problem may lie in your application and the way you are using the calls. Wireshark can tell you what happened, so you can check the operation of both the PC program and the NetBurner program.
Re: TCP/IP reliability?
I'm going to regurgiate some information from Jon Snader's Effective TCP/IP Programming.
First, You should make a distinction between a "reliable" protocol and an "infallible" protocol. TCP is reliable not infallible.
Second, you should be aware that the "reliable" aspect ends at the TCP stack not at the application on either end.
Think of TCP as guaranteeing that the data that does arrive at your application will arrive uncorrupted and in order. It doesn't guarantee it will all arrive. In my experience on a closed LAN it does all arrive but the protocol doesn't guarantee that. A lot probably depends on how much data you are sending every 250 ms. I have also found that tweaking buffer sizes can greatly affect maximize transfer speeds although most of my experience with this is PC-to-PC. There are other techniques for improving speed on the NB but I suspect that is not your issue.
There are several techniques mentioned in the book that might improve reliability in your scenario. If you need data every 250ms, set up a command to start and stop that transfer. That is, don't send a packet from the PC every 250ms, just let the NB automatically send the data. Also you can explore techniques like using seperate connections for reading and writing tcp data and/or using separate processes/threads for reading and writing. You can also implement an application level ACK/NACK or transaction protocol.
First, You should make a distinction between a "reliable" protocol and an "infallible" protocol. TCP is reliable not infallible.
Second, you should be aware that the "reliable" aspect ends at the TCP stack not at the application on either end.
Think of TCP as guaranteeing that the data that does arrive at your application will arrive uncorrupted and in order. It doesn't guarantee it will all arrive. In my experience on a closed LAN it does all arrive but the protocol doesn't guarantee that. A lot probably depends on how much data you are sending every 250 ms. I have also found that tweaking buffer sizes can greatly affect maximize transfer speeds although most of my experience with this is PC-to-PC. There are other techniques for improving speed on the NB but I suspect that is not your issue.
There are several techniques mentioned in the book that might improve reliability in your scenario. If you need data every 250ms, set up a command to start and stop that transfer. That is, don't send a packet from the PC every 250ms, just let the NB automatically send the data. Also you can explore techniques like using seperate connections for reading and writing tcp data and/or using separate processes/threads for reading and writing. You can also implement an application level ACK/NACK or transaction protocol.