hello every1. i'm currently making a little 3d game and i have a question regarding networking. after i decided to use winsock w/ async sockets to receive my msgs i coded everything but now i have the problem how and what i need to send and how to keep it synced.. currently i have a timer running which sends every 100ms the position and the rotation of the players spaceship. my message looks similar to this : T231.3T324.2T2.3R34.3R324.3 (T = translation, R = rotation) the other player then gets the FD_READ event and i try to save the values like this sscanf (themessage,"T%fT%fT%fR%fR%f", &enemy.xpos, &enemy.ypos, &enemy.zpos, &enemy.xrot, &enemy.zrot); so far so good... the bad thing is that sometimes the message isnt sent before the next one comes in. then theres one message T231.3T324.2T2.3R34.3R324.3T231.3T324.2T2.3R34.3R324.3[...]T34.3 and the rest comes with the next message... from this moment on my sscanf cant sort out the right values until the correct order is reached by coincidence (and this can take looong). until the message begins with T (x-coord) there is no movement at all... this makes the movement look crappy. can someone suggest a good way to send/receive the coords and rotation values? thx BiGF00T

is this like a flight sim style game? How you send the info is really dependant on how responsive you need it to be. If its a flight sim style game your playing over the network sending the update info only every 100ms is accually pretty slow and if you get a spike of packet loss or any kind of lag your going to see that ship bouncing all over the place.

you could just try spamming UDP packets every time the ship chances course/speed. Send the course and speed and let the other client figure out how/where its moving. then every time you update send course/speed/location....

what type of game is this supposed to be?

There seems to be rather a problem with distinguishing packets.

You almost never receive the packet in the same piece as you send it. Do NOT rely on it. It will probably do so when testing with localhost, but between different computers your packets will be cut in pieces and received thusly.

You should either define a kind of packet with a header and/or send the size of the following data up front (4 bytes should be big enough).

On the receiving end:

A) test if the received data size is big enough to hold the size. if it is continue to step B, otherwise store the received data in a buffer and keep waiting for more data.

B) test if the received data size is big enough to hold the data size AND the packet size. if it is continue to step C, otherwise store the received data in a buffer and keep waiting for more data.

C) decode the packet. if you have some data left (start of next packet) repeat at step A until you have decoded everything possible.

cannibal coder :
yes, it is a flight sim (or its supposed to be one...)
the 100ms were just there to prevent that the messages exceed the 256 byte network buffer before the message is received by the other player... i wanted to change it back when i found a solution for my problem. for now theres only full or no speed (i'll change that later) and the rotation is controlled with the mouse. i could spam packets everytime something changes but i could also send a packet every frame because theres nearly always a change in rotation if ur hand is shaking due to caffein overdosage ;)
Endurion :
so ur suggesting that if something happens and i feel like sending a message to the other player i send the message like this?:
if i would like to send the coords of the enemy spaceship then the message translationmessage would look like this
sprintf(themessage,"S%iT%f.1T%.1T%.1f",sizeof(translationmessage),x,y,z);
if the receipient would get only S16T231.3T32 and the rest would be truncated the receipient would know that theres still 7 bytes missing. the program would then store the uncomplete msg and wait until the rest comes in and append it then to the already recv'ed msg? ( i hope i understood what u said... ) is there a way to save those Ts and Rs? but i want to send more stuff later... so i dont know what could be in that message... i could save some bytes by multiplying the coordinates by 10 and later divide by 10 (to save the "." char). but optimization can wait... maybe i dont need decimal places anyway...

Yep, you understood correct already:

Save received bytes for later use if you can't decode them right away.

Better define some way to either send always same sized packets (rather unrealistic, there will always be new stuff added; but sufficient for small apps) or some way to send the current packets size.

My socket based client and server send the size of the packet as 4-byte value before sending the actual packet header and packet data.