I am making chatting based on WinSock.

I am using TCP and the function of my app is just to send/recv msg.

Generally it works fine, but i have a question about send/recv packet.

How can I make sure the packet I send has got to receiver?

As I know, TCP protocol has a guarantee the packet must be given to receiver in regular sequence.

But with my testing, i don't know if it's true or not.

I mean, for instance, i have two client apps called A and B.

And both receive packets in thread (like async).

A sends msg to B, and sometimes B doesn't receive msg from A.

So I need any way the packet is got to destination or not.

(I will put a spinner while packets are being sent)

I am sort of a beginner, so i am not sure whether my knowledge is correct.

Give me any advice or good links.

Thanks :)
So, to start I have no experience in networking in C++, so I don't know how large a packet can be or what you can actually make the program do, but can you send a description of the packet along with the packet?
example;

Packet is 1.59kb long, so variable v inside of (or right after) the packet equals 1.59, then the receiving computer checks both that Variable v made the transfer and that the packet received matches that size. If either of those are false then the full packet wasn't received...

I suppose the packet would also need a unique ID so that the receiving comp can send back a request to resend that packet.

Does that sound doable?

Again, sorry I can't supply any functions/info that would get the job done.
Please see the difference between transportation and application layer of communication model ( http://en.wikipedia.org/wiki/OSI_model ).

TCP functionality is hidden in socket API. Create your own protocol for you application. For example:
1
2
3
4
5
6
7
8
9
struct t_msg
{
char *destination; /*some abstract addr type */
char *source;
char *msg;
int size;
t_time time;
t_checksum checksum; /*sum of all the rest*/
};

When 1 side sends msg, it should set some kind of timeout. If other side wont send a message telling that it received this, timeout should write that msg got lost.

also remember that sending 2 packets 1 after another doesn't guarantee the same order on the receiver side (thus time field).
Last edited on
Topic archived. No new replies allowed.