I haven't looked at the SL Viewer code in over a decade. Maybe it's better now.
I have. It's a little better. Bulk file transfers over UDP are finally gone, moved to HTTP.
The commonly held belief was that if you want speed, you have to use UDP. But then the first thing people do is they re-implement TCP poorly at the application layer to get fragmentation, reliability, windowing or large datagrams.
Yes. The protocol Second Life uses has both unreliable and reliable UDP datagrams. "Reliable" means they have retransmits, on a fixed timer with a fixed retry count. Some get lost on overload, because the viewer's one-thread implementation discards if too many packets arrive in a frame time. In order delivery, reliability, no head of line blocking. - pick two. You can't have all three. TCP picks the first two. The Second Life protocol picks the second two. This results in occasional trouble where there really is an in-order requirement imposed by the way the state of the system changes.
Unreliable messages are common in game protocols. "Unreliable" means that lost messages should be superseded by the next one of the same type. The intent is to be consistent-eventually. Second Life is almost consistent-eventually, but not quite, which results in occasional viewer out of sync errors which make some objects in the world look wrong.
(Personally, I'd do this with one UDP path of unreliable messages, plus two TCP connections, one for high priority, low-traffic stuff, and one for lower-priority bigger stuff. Get rid of "reliable UDP". Only a very few message types, such as user mouse activity and movement updates, should be unreliable, because those can tolerate a lost message.)
I have. It's a little better. Bulk file transfers over UDP are finally gone, moved to HTTP.
The commonly held belief was that if you want speed, you have to use UDP. But then the first thing people do is they re-implement TCP poorly at the application layer to get fragmentation, reliability, windowing or large datagrams.
Yes. The protocol Second Life uses has both unreliable and reliable UDP datagrams. "Reliable" means they have retransmits, on a fixed timer with a fixed retry count. Some get lost on overload, because the viewer's one-thread implementation discards if too many packets arrive in a frame time. In order delivery, reliability, no head of line blocking. - pick two. You can't have all three. TCP picks the first two. The Second Life protocol picks the second two. This results in occasional trouble where there really is an in-order requirement imposed by the way the state of the system changes.
Unreliable messages are common in game protocols. "Unreliable" means that lost messages should be superseded by the next one of the same type. The intent is to be consistent-eventually. Second Life is almost consistent-eventually, but not quite, which results in occasional viewer out of sync errors which make some objects in the world look wrong.
(Personally, I'd do this with one UDP path of unreliable messages, plus two TCP connections, one for high priority, low-traffic stuff, and one for lower-priority bigger stuff. Get rid of "reliable UDP". Only a very few message types, such as user mouse activity and movement updates, should be unreliable, because those can tolerate a lost message.)