While NetMeeting (or the Linux NetMeeting app -- yes I know, you want Windows) may be an unwieldy monster, a lot of time went into making that unwieldy monster. Even if you only have to do 1/10th of that work, it's still a ton of work.

Netmeeting uses the H232 protocol, AFAIK, which is beyond horrible, for it needs about a million ports opened, which is a problem for firewalls. The app itself may have nice features, the ports needed is just unworkable for a lot of places. Power to the OP to come up with something better.

I will say that UDP is probably a bad choice. What you want is a TCP/IP system that has some sort of quality-of-service feature (possibly using UDP for timing? who knows), as UDP has a small packet size and (worst of all) ordering is not guaranteed. For important packets, especially ones that set up states for your program, you can't have them being lost either.

I beg to differ on this point, for I believe UDP is way better suited for transmission of images, than TCP. The initial connection should probably made through TCP, I agree, but afterwards (the sending of image data) is better suited with UDP. With TCP, all packets will arrive sooner or later, resulting in waiting on the receiving end for TCP to put the packets back in order. With UDP you might get a blur/glitch, but at least the "stream" continues. I believe this is preferable over the waiting time, especially since speed was the "itch" that made the OP consider writing his own app.

But then again, AFAIK, HTTP utilizes TCP only :( Correct me if I'm wrong on this, please :)