I'm building an oscilloscope based on the mbed that streams samples over Ethernet for processing on a PC.  Should I use TCP or UDP? I'm thinking TCP since it handles all the error correction for me, but is there good example code for implementing raw TCP using the networking libraries?

Why would you want to use UDP? The only reason I can think of is because of the overhead in data transport.

From: http://www.cisco.com/en/US/docs/internetworking/technology/handbook/Internet-Protocols.html#wp1375

"UDP is useful in situations where the reliability mechanisms of TCP are not necessary, such as in cases where a higher-layer protocol might provide error and flow control"

Thanks. I have noticed that quite a few applications that require reliability use UDP anyways and perform error correction higher up. I assumed it's because TCP's error correction is relatively inefficient in some applications.

For what it's worth, when I asked my best friend Tiffany Yep (a digital communications engineer/model) what to use, she thought TCP might be better but she wasn't sure since she had never worked on embedded systems as small as the mbed. However, she did send me a link to a video that provides a good overview of the differences. http://www.youtube.com/watch?v=KSJu5FqwEMM

My application does require fairly fast updating (at least 10FPS with a 64kB buffer), would TCP slow it down too much?

My $0.02:

I think one way of comparing TCP and UDP is to look at some examples of what they are actually used for:

TCP: Web, Email, SSH, FTP

UDP: Voice, Video (some), DNS, Online gaming, (some)

TCP using applications are characterised by needing to deliver a perfect copy of a (possibly very large) piece of data, in the right order. To achieve this, it sacrifices latency.

UDP applications want to deliver lots of small pieces of discrete data as quickly as possible where reliability is not as important as latency. In voice (VoIP) for example, you don't want to retransmit a missed packet - a fragment of speech out of context is useless, and would create even more noise on the line.

I suspect the same applies to your application - your oscilloscope doesn't want to have to wait 100ms just so a dropped packet can be retransmitted - once the time has passed, that information isn't useful. What's more, if transmission has to be paused to recover from an error, it's not clear whether you'd ever be able to 'catch up' with that delay, and your oscilloscope might be out of sync with the measurement until you reset the transmission.

Dan