I tried switching my boygroup to use TCP instead of UDP to get around the bug I wrote about in another post, only to find that the TCP update rate is a fraction of the UDP rate.
With the attached patch, when it is set to use UDP, I get an update rate of 120; but when I switch to TCP, it drops to 6-8fps. Most uncool!
This is with two high-end PCs on a private Gigabit switch. This must be a bug - surely it is not being throttled?
TCP is much slower by design, because this protocol makes sure that every network package reaches its destination. if something went wroing on thew way, it’ll resend the package. UDP lacks all those checks and sends data as fas as possible. that implies, that it’s good to implement a check on the receivers side, because it can happen, that you send 2000 values and they arrive in 2 or more chunks in 2 or more consecutive vvvv-frames - your receiver patch needs to handle that. for example with the Tokenizer (String).
… in short words
as a rule of thumb, you can say: use TCP when sending little but important data where you don’t want to miss a single bit - use UDP when sending a lot, but missing a single piece is not too bad.
@sebl - You are right, UDP has higher bandwidth/efficiency than TCP at the cost of certainty, but I assure you if TCP could only do 8 4-byte transfers per second the internet as we know it would not exist! (;^})
@ethermammoth - YES! That worked. By following the info in this MS article: http://support.microsoft.com/kb/823764 I was able to get the FPS up to 30 by applying it to the client/slave PC, and then up to 120FPS by also applying it to the server/master PC. Muchos gracias amigo!
I am going to wait and not flag this as “the solution” yet, as the article above lists things that can be done in the socket code to prevent this from happening without having to make registry changes, which would be the real solution. Devvvvs, is that viable, or are there reasons it can’t be done? I know the blocking option is out for obvious reasons…