I’m currently reintegrating my robot’s control system with my new wiznet driver and I encountered a situation. The previous model used UDP solely because the previous network device (XBee WIFI) didn’t perform well with TCP. Now that I have a choice of TCP again, I just realized that perhaps TCP isn’t such a good idea anyways.
Here’s why: The control software was build to handle message passing. There would be only 1 message in a UDP packet. TCP however could break messages across multiple packets or combine them into a single packet (it would be rare, but possible). This means the control software has to be more complex to handle those cases. Second it is possible that more than one device could be monitoring the robot at anytime. This means that while the desktop can be sending commands to move the robot, my phone might need to send an emergency command to halt the robot. There would be no point in having 2 sockets used up for this purpose, nor having to differentiate between who is sending what and when.
The question I wanted to ask is this: For NETMF and other IoT devices, is UDP usually a better choice for communications? (except cases like FTP, HTTP etc in which the answer is obviously TCP).
My application can tolerate packet loss and has built in functionality for re transmission and error correction (check sums). It also confirms receipt of packets. if packets arrive out of sequence (somehow), the application will reject the future ones; and they will have to be retransmitted.
@ andre.m - Actually that’s a good point. I am using CPU cycles on the µC to do checksums whereas TCP would do that for me. However, the data is coming from the Wiznet module via SPI! There is always a possibility that the data will be corrupt regardless of UDP or TCP. So i have to do the checksum regardless.
In the past when I was using Xbee WIFI with TCP, the device deletes the data once the µC releases the CS pin of SPI port. However because there was no way to inform Xbee that the checksum failed, there was no way to get back the lost packet. So TCP in that senario was actually a hindrance.
Somewhere there’s an insightful quote about people who reimplement tcp over udp, but I can’t find it with a cursory search. The point is, if you need what TCP gives you (guaranteed delivery, packet order, etc) then use TCP, don’t reimplement all that over UDP. You might be better than all the people who designed and implemented TCP, but you might also not be better than them.
Fun fact: IPv6 doesn’t have header checksumming. It does, however, require checksums in UDP packets (something that UDP over IPv4 does NOT require). TCP always checksums the whole packet.
@ Mr. John Smith - I’d say that if you’re seeing much of any corruption over the SPI bus, then you should look into that. Short traces, proper grounding, etc. Slow it down, if you need to. If you have a scope handy, I’d check for noise.
@ godefroi - Stray EMI and magnetic fields during normal operation can cause errors on the SPI bus. Only way round is to shield it. It’s cheaper to mitigate errors than to try and avoid them completely.
