0

I am working on a project which requires sensor information to be obtained from multiple embedded devices so that it may be used by a master machine. The master currently has classes which contain backing fields for each sensor. Data is continuously read on each sensor and a packet is then written and sent to the master to update that sensor's backing field. I have little experience with TCP/UDP so I am not sure which protocol would work better with this setup.

I am currently using TCP to transfer the data because I am worried about data on our rotary encoders being received out of order. Since my experience with this topic is limited, I am not sure if this is this a valid concern.

Does anyone with experience in this area know any reasons that I should prefer one approach over the other?

bubbleking2
  • 1
  • How real-time is it? TCP retransmission might mean you get old values (instead of no values with UDP) – Erik Ekman Jan 09 '13 at 15:39
  • Instantaneous is desired. The values on the master PC are supposed to represent the current values the sensors are detecting. – bubbleking2 Jan 09 '13 at 15:59

2 Answers2

1
  • How much you care about getting know a packet was delivered?
  • How much you care about getting know a delivered packet was 100% correct?
  • How much you care about the order of packet delivery?
  • How much you care about the peer is currently connected?

If the answers were "I care a lot", you'd prefer to keep on using TCP because it ensure all four points.

The counterpart is that UDP could be more lightweight and fast to handle if you manage small packets.

Anyway, it's not so easy choose this or that. Just try.

And read this brief explanation: http://www.cyberciti.biz/faq/key-differences-between-tcp-and-udp-protocols/

Davide Berra
  • 6,387
  • 2
  • 29
  • 50
0

I'm no expert but it seems this might be relevant:

Do you can about losing data?

If so, use TCP. Error recovery is automatic.

If not, use UDP. Lost packets are not re-sent. I also believe ordering here is not guaranteed.

Paul Collingwood
  • 9,053
  • 3
  • 23
  • 36