void main()
{
sSendPacket(LoginGuy);
sSendPacket(KillGuy);
}
void main()
{
sSendPacket(KillGuyAtTemple);
sSendPacket(PutPlayerOneAtTemple);
}
Winsock TCP packet arrival order...
Author
Well, the compiler and I have been throwing blame at eachother for a phenomena occuring in my game. I now think its due to the way TCP handles packets; or better put, my lack of knowledge of how TCP handles packets.
Here is my understanding of the TCP protocal.
If we label two packets, packet one being named "Login Guy" and packet two being named "Kill Guy"...
Sending these packets doing something like this...
... can in result LoginGuy or KillGuy arriving before the other; however, the sub-packets that compose a packet will arrive in order.
Therefor, if your game does something like this...
... its possible that it will put PlayerOne at the temple and then kill him.
Is this the case? And if so, can I specify any properties of winsock to enforce that the order in which I send packets is the order in which they arrive?
No, TCP sockets act as streams so the data you send out always arrives in the order you send it (and you lose packet boundary information). UDP is another matter and does work pretty much as you describe - then again it also doesn't actually guarantee the packet arrives at all.
I am fairly certain the instant I post this that someone else will correct me.
But the answer to your question is no there is no way to guarantee the order in which two separate TCP packets arrive.
The reason for this is simple. Packet A may be routed via a distant satellite orbitting an entirely different planet and packet B gets routed via a router located next door to your, there for packet B gets to you first.
You can get round this by using what I call meta packets, place all your order sensitive 'packets' into a stream and then send that. In fact this would be a more efficvient way of doing things. Look up the TCP protocol and you will see what I mean, there is a significant overhead to establishing a TCP connection. Which is why alot of people use UDP (for delta data).
But the answer to your question is no there is no way to guarantee the order in which two separate TCP packets arrive.
The reason for this is simple. Packet A may be routed via a distant satellite orbitting an entirely different planet and packet B gets routed via a router located next door to your, there for packet B gets to you first.
You can get round this by using what I call meta packets, place all your order sensitive 'packets' into a stream and then send that. In fact this would be a more efficvient way of doing things. Look up the TCP protocol and you will see what I mean, there is a significant overhead to establishing a TCP connection. Which is why alot of people use UDP (for delta data).
Author
Quote:Original post by ZQJ
No, TCP sockets act as streams so the data you send out always arrives in the order you send it (and you lose packet boundary information). UDP is another matter and does work pretty much as you describe - then again it also doesn't actually guarantee the packet arrives at all.
I believe each packet is a stream, but the socket itself is not a stream. Thus, packets may arrive out of order.
One of the earlier glitches in my game was resolved by checking that the first packet that arrived was the login packet instead of the surrounding monsters packet.
What information are you basing your knowledge from?
Quote:
I am fairly certain the instant I post this that someone else will correct me.
You bet! [wink]
No, TCP *guarantees* that packets will be received *in order*.
Always. No exceptions.
Of course, it can't control when a packet physically arrives, but it is kept in an internal buffer until all preceding packets have been received.
But from the point of view of your application, the packets will arrive in the order you sent them.
http://linux.about.com/library/cmd/blcmdl2_socket.htm
A TCP/IP connection is create with the socket function using socket(PF_INET, SOCK_STREAM, 0);
And again here.
Quote:
SOCK_STREAM
Provides sequenced, reliable, two-way, connection-based byte streams. An out-of-band data transmission mechanism may be supported.
A TCP/IP connection is create with the socket function using socket(PF_INET, SOCK_STREAM, 0);
And again here.
Quote:
It (TCP) provides a reliable, stream oriented, full duplex connection between two sockets on top of ip(7), for both v4 and v6 versions.
Author
Quote:Original post by Spoonbender
No, TCP *guarantees* that packets will be received *in order*.
Always. No exceptions.
Of course, it can't control when a packet physically arrives, but it is kept in an internal buffer until all preceding packets have been received.
But from the point of view of your application, the packets will arrive in the order you sent them.
Your certian that the packets your application view are in order; as opposed to the sub-packets composing each packet.
The reason I'm hesitant to believe this, is because I've been informed otherwise during my time of learning Winsock. DeltaVee's post describes my understanding of TCP exactly, even his method of "meta" packets I had considered previously using in my application for order sensitive packets.
Quote:Original post by SpoonbenderQuote:
I am fairly certain the instant I post this that someone else will correct me.
You bet! [wink]
hehe :P
Quote:Original post by Spoonbender
But from the point of view of your application, the packets will arrive in the order you sent them.
Unless he is openning a socket then closing it for every packet.
Quote:Original post by Thevenin
Your certian that the packets your application view are in order; as opposed to the sub-packets composing each packet.
Everything you send (over the same connection, obviously) will arrive in order.
No exceptions, no special cases. If you send something, it arrives after whatever you send previously, and before whatever you send next. Whether it's sent using one or more send()-calls, whether it's part of the same char[] is irrelevant.
Quote:
The reason I'm hesitant to believe this, is because I've been informed otherwise
You've been informed wrong then? [wink]
ZQJ just posted some links you might want to check out to convince yourself.
But the entire point in TCP is to offer a service with virtually every commonly useful feature. Reliability, in order, connection-oriented, and dozens of other things.
UDP is the discount version, guaranteeing only that a packet will either arrive unchanged or not arrive at all.
Dusts off his Network Programming for Microsoft Windows
TCP guarantees the order of individual packets sent
UDP does not (doesn't even gaurantee arrival)
TCP guarantees the order of individual packets sent
UDP does not (doesn't even gaurantee arrival)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
