2
votes

I'd like to make a chatting program using win socket in c/c++. (I am totally newbie.) The first question is about how to check if the client receives packets from server. For instance, a server sends "aaaa" to a client. And if the client doesn't receive packet "aaaa", the server should re-send the packet again.(I think). However, I don't know how to check it out. Here is my thought blow. First case.


Server --- "aaaa" ---> Client.
Server will be checking a sort of time waiting confirm msg from the client.
Client --- "I received it" ---> Server.
Server won't re-send the packet.


The other case.
Server --- "aaaa" ---> Client.
Server is waiting for client msg until time out
Server --- "aaaa" ---> Client again.

But these are probably inappropriate. Look at second case. Server is waiting a msg from client for a while. And if time's out, server will re-send a packet again. In this case, client might receive the packet twice.

Second question is how to send unlimited size packet. A book says packet should have a type, size, and msg. Following it, I can only send msg with the certain size. But i want to send msg like 1Mbytes or more.(unlimited)

How to do that?

Anyone have any good link or explain correct logic to me as easy as possible.

Thanks.

2
TCP already handles automatically resending the packet.Captain Obvlious
Unless user2655083 wants to use UDP for some reason or is writing another protocol - gulp.d-_-b
Unless you are specifically looking to learn the nuances of low-level TCP/UDP programming, you might want to look into either an abstraction layer, such as libevent or a messaging library such as zeromq or rabbitmqkfsone
I suggest you go read some tutorials online and find some sample source code. Stack overflow isn't here to teach you how to program a concept. read the help section at the top for what types of questions are appropriate.xaxxon

2 Answers

1
votes

Use TCP. Think "messages" at the application level, not packets.

TCP already handles network-level packet data, error checking & resending lost packets. It presents this to the application as a "stream" of bytes, but without necessarily guaranteed delivery (since either end can be forcibly disconnected).

So at the application level, you need to handle Message Receipts & buffering -- with a re-connecting client able to request previous messages, which they hadn't (yet) correctly received.

Here are some data structures:

class or struct Message {
    int type;              // const MESSAGE.
    int messageNumber;     // sequentially incrementing.
    int size;              // 4 bytes, probably signed;  allows up to 2GB data.
    byte[] data;
}

class or struct Receipt {
    int type;              // const RECEIPT.
    int messageNumber;     // last #, successfully received.
}

You may also want a Connect/ Hello and perhaps a Disconnect/ Goodbye handshake.

class Connect {
    int type;              // const CONNECT.
    int lastReceivedMsgNo; // last #, successfully received.
    // plus, who they are?   
    short nameLen;
    char[] name;
}

etc.

If you can be really simple & don't need to buffer/ re-send messages to re-connecting clients, it's even simpler.

You could also adopt a "uniform message structure" which had TYPE and SIZE (4-byte int) as the first two fields of every message or handshake. This might help standardize your routines for handling these, at the expense of some redundancy (eg in 'name' field-sizes).

1
votes

For first part, have a look over TCP. It provides a ordered and reliable packet transfer. Plus you can have lot of customizations in it by implementing it yourself using UDP. Broadly, what it does is,

Server: 1. Numbers each packet and sends it 2. Waits for acknowledge of a specific packet number. And then re-transmits the lost packets.

Client: 1. Receives a packet and maintains a buffer (sliding window) 2. It keeps on collecting packets in buffer until the buffer overflows or a wrong sequenced packet arrives. As soon as it happens, the packets with right sequence are 'delivered', and the sequence number of last correct packet is send with acknowledgement.

For second part: I would use HTTP for it. With some modifications. Like you should have some very unique indicator to tell client that transmission is complete now, etc