TCP vs UDP with index
Author
As I understand from this , RakNet uses an index system to make sure packages arrive and that they are in the right order.
My question is which method is faster, transmitting a DWORD along with the data using UDP or using TCP?
A simple answer to your question would be to consider the size of the TCP header - (at least) 20 bytes - vs. the size of the UDP header - 8 bytes. So an extra four bytes on a UDP packet will still make it smaller than a TCP packet.
But you may as well ask "is a car faster then a motor bike?" In certain situations, a motor bike is faster (e.g. in a straight line) wheres in other situations, a car would be faster (e.g. around corners).
But you may as well ask "is a car faster then a motor bike?" In certain situations, a motor bike is faster (e.g. in a straight line) wheres in other situations, a car would be faster (e.g. around corners).
Author
Quote:Original post by Codeka
A simple answer to your question would be to consider the size of the TCP header - (at least) 20 bytes - vs. the size of the UDP header - 8 bytes. So an extra four bytes on a UDP packet will still make it smaller than a TCP packet.
But you may as well ask "is a car faster then a motor bike?" In certain situations, a motor bike is faster (e.g. in a straight line) wheres in other situations, a car would be faster (e.g. around corners).
In what situation would TCP be faster?
The advantages are more than just the packet size but more of being able to tailor the way your protocol reacts (ie - resend behaviors when traffic backs up) and scaleability (socket overhead when there are MANY connections to server) and router/firewall issues (where UDP might get thru easier) ontop of customization/control at a lower level (throttling feedback by signalling up to the Application level).
TCP implementation have hooks for some of their behaviors and tuning parameters, but if you write it yourself you could make it more customized/innovative (though its not a trivial task).
TCP implementation have hooks for some of their behaviors and tuning parameters, but if you write it yourself you could make it more customized/innovative (though its not a trivial task).
TCP is faster for streaming data where packet-loss is not acceptable (e.g. HTTP, etc) - that's why TCP was invented, after all.
Also, TCP is likely faster for bulk transfers across unknown and changing network topology, since it adapts the MTU, whereas you have to guess and pray (or implement a similar path MTU discovery) with UDP.
Also, it may be faster on certain links, for example PPP (there's TCP header compression, but no such thing as UDP header compression).
Speed is not what usually matters, though. Latency versus reliability and in-order delivery are the things that matter. If something must have minimum latency, then UDP is your friend, if it must be reliable and in-order, then it's TCP.
Also, it may be faster on certain links, for example PPP (there's TCP header compression, but no such thing as UDP header compression).
Speed is not what usually matters, though. Latency versus reliability and in-order delivery are the things that matter. If something must have minimum latency, then UDP is your friend, if it must be reliable and in-order, then it's TCP.
Author
I have an idea, what if I used SOCK_RAW to create own protocol? Basically the server would keep a list of all connected clients and the client would sent an index of it's position in the list. I would also have the index of the data packet, I would be able to get the header down to 4 bytes, would this be greatly faster then UDP or TCP? Is there more then just the header size to take into account as far as speed?
It is faster, but your data might not be intact. So you will want to attach some sort of checksum also (for verifying packet is correct).
You should probably use tcp if you need all packets to arrive, and without corruption.
For instance, if you send a stream of position updates, then it does not mater if you drop a packet as you can always use the next position update. It might also take longer for tcp to rerequest the broken packet and getting it resent, then simply waiting for the next position update.
If, instead, you are sending position as a series of movements, then you will always need all previous packets for calculating the current position.
The only thing that will get better by using UDP is latency. Many protocols implemented ontop of UDP actually sends more data over the network by adding data redundancy. The data redundancy is used to make the application being able to handle some errors in the packet. As bits can change during the transmission of an UPD packet. The network can also drop UPD packets.
You should probably use tcp if you need all packets to arrive, and without corruption.
For instance, if you send a stream of position updates, then it does not mater if you drop a packet as you can always use the next position update. It might also take longer for tcp to rerequest the broken packet and getting it resent, then simply waiting for the next position update.
If, instead, you are sending position as a series of movements, then you will always need all previous packets for calculating the current position.
The only thing that will get better by using UDP is latency. Many protocols implemented ontop of UDP actually sends more data over the network by adding data redundancy. The data redundancy is used to make the application being able to handle some errors in the packet. As bits can change during the transmission of an UPD packet. The network can also drop UPD packets.
Quote:I have an idea, what if I used SOCK_RAW to create own protocol?
Every firewall on the planet would block your messages. In fact, it's unlikely your packets would even make it off your ISPs network.
For raw low-latency transmission, it's hard to beat UDP.
For bulk throughput over time on the general Internet, it's hard to beat TCP.
Quote:Original post by hplus0603Quote:I have an idea, what if I used SOCK_RAW to create own protocol?
Every firewall on the planet would block your messages. In fact, it's unlikely your packets would even make it off your ISPs network.
For raw low-latency transmission, it's hard to beat UDP.
For bulk throughput over time on the general Internet, it's hard to beat TCP.
It sounds to me that some of the posters think that you always use UDP in a simplest way instead of building up your own protocols as complex or simple as desired (the primary advantage being able to make it behave the way you want -- again though requiring the work to get it to work as you want). Except for simple one-shot (sessionless) request and answer type usage you have to develop SOME kind of protocol (for the 'session' connection at minimum)
For some bulk transmission mechanisms such as a large block transfer (where the entire block is sent intact and expected to be received at one time intact on the other side) you can optimize the ACK mechanism in a 'bulk way' eliminating alot of small packets by sending back requests for only the missing subblock packets.
I did that for a custom block data transfer protocol (imbedded alongside the ordinary reliable packet delivery and the out of band packets) where it at intervals sent grouped resend requests and some final handshake confirmation at to make sure all the ACKs got thru at the end. It had aditional complexity in that it was treated as a lower priority task (letting the OOB or reliable packet xfer have higher priority).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement