Questions about Network Protocols

Started by
6 comments, last by klems 17 years, 6 months ago
Hi, I'm an extreme c++ noob programmer (that can only do the cout, cin, arrays, pointers, and classes). Because of that, it's safe to make these assumptions: - I don't have any idea of what #pragma means - I still got problems with my compiler when using non-standard libraries and linking dll - I don't even know why people created weird terms such as LPCSTR I got top programming scores in highschool (they use easy Java), but in reality I only know miniscule of the art of programming T.T. I'm currently working on network programs as a practice to making games. Alrite, so I've heard about a few network protocol terms which are "TCP" and "UDP". So far, I've learned that TCP makes sure that data is sent correctly, and that UDP doesn't care about that. So here are my questions: 1. Is using TCP slower than using UDP when sending data? (i.e. latency) 2. What anomalies usually occur when using UDP ? (e.g. can you actually lose data during transfer?) 3. For a chatting program, which protocol is better? 4. For an online/network game, which protocol is better? Since I think people will generally answer UDP, how do I cope with the anomalies that occur when using UDP? 5. What happens if somehow data transfer was not completed when using TCP? (e.g. My little sister accidentally tripped on the network cable) Will data still be sent in its imperfect form? I got no volunteers to test this for me. 6. Same question as No.5 but this time with UDP. 7. I heard that UDP does not make sure data is received in the order that they are sent. How do I cope with this? e.g. I want to send game data in this format: [1 byte, action type flag][2 bytes, ID of the player involved][4 bytes, action parameter value] How do I make sure the receiver knows which bytes belong to which information? 8. Unrelated with the topic, but I would be thankful to anyone who can help me with this. A link to a tutorial would be a great help too. How do I get the source code of web pages using basic c++ runtime library? I wanna try creating a "PM manager" to ease the process of opening forum PMs.
Advertisement
1. Is using TCP slower than using UDP when sending data? (i.e. latency)
Yes, TCP is slower, but more reliable. Packets will always be received in order with TCP.

2. What anomalies usually occur when using UDP ? (e.g. can you actually lose data during transfer?)
I don't believe data can be lost in transfer, from what I read at beejs, it seems the problem involves packets arriving out of order.

3. For a chatting program, which protocol is better?
Probably TCP.

4. For an online/network game, which protocol is better?
Since I think people will generally answer UDP, how do I cope with the anomalies that occur when using UDP?
UDP. You'll probably have to send enough information so that if you receive a packet thats out of order, you can still update an entity properly. Otherwise, you can set up a system so that it'll wait for the next packet that is supposed to be received. Basically you'll need a way to identify when a packet was sent.

5. What happens if somehow data transfer was not completed when using TCP?b]
(e.g. My little sister accidentally tripped on the network cable)
Will data still be sent in its imperfect form? I got no volunteers to test this for me.

Can't help you with this one

6. Same question as No.5 but this time with UDP.
or this one

7. I heard that UDP does not make sure data is received in the order that they are sent. How do I cope with this?
e.g. I want to send game data in this format:
[1 byte, action type flag][2 bytes, ID of the player involved][4 bytes, action parameter value]
How do I make sure the receiver knows which bytes belong to which information?

If you send [1 byte, action type flag][2 bytes, ID of the player involved][4 bytes, action parameter value] in one packet, it will receive like that, but if you send the data individually, it may not. The out of order things usually means that if you send two packets, sometimes the second packet will arrive before the first.
ooo, thank you very much.
Now I understand how it works - at least.

Extremely beneficial indeed, a positive increase has been added to your rating.
I suggest checking the Forum FAQ for the Networking and Multiplayer forum -- it has answers to the questions you asked, as well as pointers to some tutorials and libraries that might help you.
enum Bool { True, False, FileNotFound };
Quote:Original post by ScottC
1. Is using TCP slower than using UDP when sending data? (i.e. latency)
Yes, TCP is slower, but more reliable. Packets will always be received in order with TCP.


Thats not 100% true. Assuming a perfect world (and you have TCP set up correctly), TCP and UDP will run at about the same speed (altough UDP does have smaller headers). What ScottC is referring to though is the fact that if theres an error or a packet is dropped then TCP/IP will wait untill that packet arrives. UDP on the other hand will not.

Quote:
2. What anomalies usually occur when using UDP ? (e.g. can you actually lose data during transfer?)
I don't believe data can be lost in transfer, from what I read at beejs, it seems the problem involves packets arriving out of order.


Packets can definately be lost using UDP. The game I just created has packets go missing all the time (by all the time I mean about 1 packet every 2 minutes or so). Its usually caused thanks to routers fragmenting the packets or simply dropping them.

Quote:
4. For an online/network game, which protocol is better?
Since I think people will generally answer UDP, how do I cope with the anomalies that occur when using UDP?
UDP. You'll probably have to send enough information so that if you receive a packet thats out of order, you can still update an entity properly. Otherwise, you can set up a system so that it'll wait for the next packet that is supposed to be received. Basically you'll need a way to identify when a packet was sent.


UDP isn't better than TCP/IP. It really depends on the game as to which should be used. If your more concerned with latency than getting every single packet thats sent then go with UDP (generally FPS games would fall under here). If your more concerned with getting every single packet (and in order) then go with TCP/IP (some RPGs are a good example of this).

Although if you really want you can always write the functionality of TCP/IP into a wrapper class for UDP.

Quote:
7. I heard that UDP does not make sure data is received in the order that they are sent. How do I cope with this?
e.g. I want to send game data in this format:
[1 byte, action type flag][2 bytes, ID of the player involved][4 bytes, action parameter value]
How do I make sure the receiver knows which bytes belong to which information?



Well if you really need the data recieved in order, don't use UDP. Instead use TCP/IP. Or you can always build a wrapper class (or download one of the many out there) that will do the TCP/IP functionality using UDP.

As far as knowing what bytes are what, read what ScottC wrote.
Quote:Original post by TheFez6255if theres an error or a packet is dropped then TCP/IP will wait untill that packet arrives. UDP on the other hand will not.
Meaning that if the packet is somehow lost / dropped, then my program will stop receiving the next packet and wait forever for the lost packet?

What's usually the latency difference between TCP and UDP if let's say... I'm playing with a dial-up from South East Asia to USA (my point is, halfway round the world)?
Quote:Original post by dadads
Quote:Original post by TheFez6255if theres an error or a packet is dropped then TCP/IP will wait untill that packet arrives. UDP on the other hand will not.
Meaning that if the packet is somehow lost / dropped, then my program will stop receiving the next packet and wait forever for the lost packet?

What's usually the latency difference between TCP and UDP if let's say... I'm playing with a dial-up from South East Asia to USA (my point is, halfway round the world)?

If a packet is lost, then the recieving end wont sit there waiting forever, because how did it know that the packet was on its way to begin with in order to start waiting?

There is no real latency difference between TCP and UDP... UDP packets are slightly smaller...

If you're sending synchronous data, like a chat program, you want TCP coz it will make sure no packets get lost. If you want a simple network method thats easy to understand without getting your hands dirty, just stick with TCP.

If you are constantly spamming data (such as a players position in an first person shooter) then it is better to use UDP, because it doesnt matter if a packet gets lost, because the next packet has newer data anyway. However, you will have to include a sequential number in each packet, coz you might send #1,#2,#3 but recieve #1,#3,#2 - in this case you would need to ignore packet #2 because it has older info than #3...


For a good view on the pro's and con's of UDP check out this article on John Carmacks journey from TCP to UDP:
http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking


[edit]
Quote:Original post by dadads
7. I heard that UDP does not make sure data is received in the order that they are sent. How do I cope with this?
e.g. I want to send game data in this format:
[1 byte, action type flag][2 bytes, ID of the player involved][4 bytes, action parameter value]
How do I make sure the receiver knows which bytes belong to which information?

A good practice is to make the first byte (or 2, or 4) of each packet some kind of packet type ID.
So the reciever can check this ID and see what to do with it.
E.G.
if the byte == 1, then the rest of the data is a system message
if the byte == 2, then the next 2 are a player ID, then the next 4 are an action ID etc...

This ID at the start of the packet is what you would call a header. You should use the same header in all of your packets to make life easier. You can define it easily with something along these lines:
typedef struct{    unsigned short packet_type;    unsigned int   packet_number;}my_packet_headertypedef struct{    my_packet_header header;    int player_id;    char message[256];}chat_packetvoid SendChat( std::string message ){   chat_packet thePacket;   thePacket.header.packet_type = ID_CHAT;   thePacket.header.packet_number = 1234;   thePacket.player_id = 1234;   strcpy( thePacket.message, message.c_str() );   gpNetwork->SendData( thePacket, sizeof(thePacket) );}

BTW, i reccomend you only use this code for illustrative purposes (for example, bad things will happen in my code if SendChar is passed a message longer than 256 characters!).

Quote:Original post by dadads
8. Unrelated with the topic, but I would be thankful to anyone who can help me with this. A link to a tutorial would be a great help too.
How do I get the source code of web pages using basic c++ runtime library?
I wanna try creating a "PM manager" to ease the process of opening forum PMs.

You have to use the HTTP prototcol for that... The standard library doesnt implement HTTP. So you can either implement it yourself, or download someone elses code who allready has (such as cURL http://curl.haxx.se/).
They have a tutorial, but it might be a bit hard for a newbie:
http://curl.haxx.se/libcurl/c/libcurl-tutorial.html

[Edited by - PhilMorton on October 6, 2006 12:31:38 AM]
Allways question authority......unless you're on GameDev.net, then it will hurt your rating very badly so just shut the fuck up.
Quote:5. What happens if somehow data transfer was not completed when using TCP?
(e.g. My little sister accidentally tripped on the network cable)
Will data still be sent in its imperfect form? I got no volunteers to test this for me.
The receiver will wait for a while, then decide that the connection is broken and that further data exchange is impossible unless you connect anew.

Quote: 6. Same question as No.5 but this time with UDP.
Since UDP is not connection oriented, nothing. If you're using UDP and want to know when a machine can no longer be reached you have to implement that functionality for yourself. If your program expects a constant stream of packets it may be safe to assume that if no packet has arrived for n seconds the connection is dead. If it doesn't you'll have to send a packet to which the machine you're communicating with is supposed to respond and consider the machine down if the response doesn't come, though it might be better to use TCP if you're not expecting that kind of traffic.

This topic is closed to new replies.

Advertisement