Sending small strings through sockets (lag problem)

[kfaday]

Hello.
I'm doing a small drawing application, which is multi-client.
I've implemented a pen. When you press the button and keep the mouse pressed you insert CPoints in a list, and i create a string with the points and send it with the socket.
The problem is, that i'm sending many points a second (i send in OnMouseMove) and the other user receives them, but sometimes not in order.
For example i send a,b,c,d,e,f and the user receives a,b,d,c,e,f.
How could i solve that? i tought of a buffer of ten points, so when ten points are written, a string with points is sent, to avoid the order problem.
i am sure somebody has had this problem before (or something similar).. what could i do?

thanks!!!

[Andreas Masur]

[Moved thread]

[TheCPUWizard]

You should not have the order problem, IF you are checking the return (error) code of EVERY function call and taking the appropriate action.

If a packet gets dropped, "future" packets MAY get passed through, but are flagged as such. This is because some applications my perform better in this fashion.

Make sure you check EVERY return code, even if it is something that could *never* fail.

[kfaday]

well, i should have explained the scenario better. It's a jabber client, something like msn messenger. I send the strings to the server, and the server sends the strings to the other client.
that's why i have the order problem. Every point is sent, so there are no errors when i send them

[Mathew Joy]

I think your problem have nothing much to do with winsock. Because winsocket does not have the ordering problem. The most likely cause is the threading issue. What method do you use for sending and recving data? (MFC, APIs[blocking, asyncsock,iocp...])

[kfaday]

yes, it's a problem of the server.. i'm using MFC's CSocket.
i was just asking for advice how to sort that problem. I'm doing it right now by creating a buffer and sending some information in order.

[Mathew Joy]

I don't use MFC for winsock because of its inefficiency and buggy nature. What you can do is to try to serialize the send, like using synchronizing objects like critical section, so that you are issueing next send only if the current send is over.

[j0nas]

I don't understand this. First thing to verify is that all points are being sent in correct order from the first client? Next thing to verify is that all points are received in correct order at the server. Third thing to verify is that the server sends all points in correct order to the second client. Last thing to verify, is that the second client receives all points in correct order (that obvously doesn't happen).

What I don't understand is, why you would run into a sync'ing problem?!?... I mean, TCP/IP (and sockets) basically synchronizes everything for you--or am I missing something here??

Good luck.

PS. I hope you don't use UDP... becuase then you may run into big sync problems.

[Mathew Joy]

Originally posted by j0nas
What I don't understand is, why you would run into a sync'ing problem?!?... I mean, TCP/IP (and sockets) basically synchronizes everything for you--or am I missing something here?? Yea...a small thing.

There is a similar issue in models such as IOCP. It was thought (by many)that recv() do complete out-of order and the application should take care of it. But actually it was the threading issue. I don't know much about MFC sockets but I do know that it does have problems other than performance issues. This can be one of them though honestly, I haven't heard it before, but it could be possible since the OP says he send many times times a sec. The OP can try sync'ing both send and recv if it solves then we know that this is the problem(either MFC or app threads).