Quote:
Originally Posted by slavik262
Sure, but we think that a lot of the slowness was caused by TCP. For example, if a frame of the video being transmitted gets screwed up, it's not that big of a deal using UDP, especially if you have a high framerate. You can just drop the frame and wait for the next one (no big deal if you're getting a good 20 of them every second - the user will barely notice). If we use TCP and the same thing happens to a packet, the receive() function stops the entire program execution, sends a request to resend the packet, and waits for the packet to get sent again, all for just one frame (or even just one part of a frame). You're making the entire system, which could be better spending its time just displaying the next frame(s), wait on just one frame instead of moving on.
|
I believe you (or someone else) mentioned sending video over the UserData dashboard data mechanism last year... it is implemented as UDP transfers, and only marginally smaller packets that you get with raw datagrams. I'm not aware of any changes that would have made this stop working. Is this method no longer feasible or desirable for some reason? This method has about 47kBytes/s throughput.
-Joe