191–198 of 198 posts
Earlier quoted context omitted.
Who chooses when a UDP packet is dropped? The freaking network adapter device driver which is what I said in the first place!
There is a lot more in the transmission chain than just that driver.
Earlier quoted context omitted.
CNN has a video transfer tool for b2b subscribers that uses multiple UDP streams to increase transfer speeds. Instead it saturated and brought down our company firewalls, which were older and our main bottleneck. All for just a potentially few more megs of speed on TB sized videos. Gotta be careful with UDP.
> a video transfer tool for b2b subscribers that uses multiple UDP streams That sounds like FASP ( http://asperasoft.com/technology/transport/fasp/ )
Earlier quoted context omitted.
CNN has a video transfer tool for b2b subscribers that uses multiple UDP streams to increase transfer speeds. Instead it saturated and brought down our company firewalls, which were older and our main bottleneck. All for just a potentially few more megs of speed on TB sized videos. Gotta be careful with UDP.
That just sounds like your firewalls are made of pentium pros and duct tape. TCP can oversaturate a connection too, and a firewall should be able to handle large packets at line rate.
Earlier quoted context omitted.
You're only considering the case when no packets are lost. Once TCP drops a packet, data sits in the receiving buffer getting older and older instead of being delivered to the program.
It's way more rediculous than you think. OS network stacks try to do the reasonable thing in most cases if possible. In the case of Linux TCP Vegas is very unlikely to drop any packet since the main algorithm is RTT based not drop. Red and hopefully codel can combat buffer bloat to some point but in the end all packets go to the same place
The main difference between TCP and UDP, as this programmer discovered, relates to quality of realtime service. Times to use UDP over TCP * When you need the lowest latency * When LATE data is worse than GAPS (loss of) in data. * When you want to implement your own form of error correction to handle late/missing/mangled data. TCP is best when * You need all of the data to arrive, period. * You want to automatically m…
People talk like most games use UDP, but they don't. Pretty much the only genre that does is First Person Shooters. MMOs (like world or warcraft) MOBAs (like Dota) RTSs (like Starcraft) Action RPGs (like Diablo) All of these are action games and use TCP. In most genres people would rather have the simulation pause when there is packet loss, and then run fast to catch up rather than have unreliable data about player l…
Earlier quoted context omitted.
>1) Bulk data transfer doesn't work over UDP. Tell that to all of the people that use TsunamiUDP to do bulk data transfer. It uses TCP as a control protocol, but the data transfer is all UDP.
It sounds like they would agree. Bulk data transfer doesn't work over UDP, but it can work over UDP and TCP.
Earlier quoted context omitted.
Nobody ever mentions that UDP has one additional feature that TCP doesn't: preserving of message boundaries.
A datagram-like protocol with the reliability of TCP might be nice. I once implemented a communications protocol that worked with variable-length independent messages over TCP. It felt a little silly pushing distinct datagrams into a stream, that would be chopped up into a packets, sent to another PC, where the OS would then reassemble those packets back into a stream, only to be chopped up again in messages. Impleme…
Earlier quoted context omitted.
If you do the obvious work to convert UDP to a reliable streaming mechanism, you will generally more-or-less reinvent TCP, only probably more poorly, and would probably be better off just using TCP. UDP is a good choice when you have options or requirements that TCP can't accommodate. For instance, the classic case of streaming audio has both; it both requires timely delivery and has some very sophisticated technique…
Why are so many comments here ignoring the purpose of the article? The purpose of this is for games, not web traffic or torrent2.0. In real time games where you're syncing physics states or player locations data >200ms isn't just useless it's actually negative. This article is 2+ years old, and is the foundation I suspect for libyojimbo which hybridizes UDP low latency communication for large player real time games a…