Chat implementation using TCP

[myself_rajat]

Dear All,

I am working for a client server chat implementation. In that whatever a client will send to the server, the server will
send back to all the existing client in the conference, including sender, like yahoo group chat.
I am using TCP for that.
Now my question is, as TCP is a stream protocol, and sends the given stream by breaking into segments, depending on the window size. So just consider a scenerio,
There are 3 clients c1, c2, c3. Connected to server. Sending simultaneously some messages. Though before sending to server we will prepend a header to know about the user-id and end_of_message flag, but it may be the case when server will be sending
data(received segments) to clients, the clients will be having segments in a multiplexed manner, like first seg of c1's message, second seg of c2's message like that. So how we can distinguesh about which segment belongs to which client, So that after receiving whole message we can display accordingly.

[ellzey]

Dear All,

I am working for a client server chat implementation. In that whatever a client will send to the server, the server will
send back to all the existing client in the conference, including sender, like yahoo group chat.
I am using TCP for that.
Now my question is, as TCP is a stream protocol, and sends the given stream by breaking into segments, depending on the window size. So just consider a scenerio,
There are 3 clients c1, c2, c3. Connected to server. Sending simultaneously some messages. Though before sending to server we will prepend a header to know about the user-id and end_of_message flag, but it may be the case when server will be sending
data(received segments) to clients, the clients will be having segments in a multiplexed manner, like first seg of c1's message, second seg of c2's message like that. So how we can distinguesh about which segment belongs to which client, So that after receiving whole message we can display accordingly.

I don't quite understand the question. The question ended up being "How can we distinguish about which segment belongs to which client?". I think the simple answer here is keep track of your socket file descriptors. E.g.,


#define MAX_CONN 10

struct __sock {
char *nickname; /* a unique identifier for a connection */
int sock; /* socket descriptor for this session */
struct __sock *next;
};

struct __sock *connected[MAX_CONN];



So whenever anyone connects, and authenticates or whatever, you can keep track of the socket number in a list of sorts.

so if client a sends a msg, you can do


#define MAX_MSG 1024
int send_to_all(struct __sock **head, struct __sock *from, char *msg)
{
struct __sock *tmp = *head;
char *from_user = from->nickname;
char *whole_msg = (char *)malloc(MAX_MSG);
int len=0;

len = snprintf(whole_msg,MAX_MSG-1,"%s said: %s\n", from_user,msg);

if(len<=0)
{
free(msg);
return -1;
}

while(tmp != NULL)
{

if(tmp->sock>1) send(tmp->sock, whole_msg, len-1, 0);
tmp = tmp->next;
}
return 0;
}

[myself_rajat]

Sorry ellzey, if I couldn't explain my problem. Actually this receiving problem I am considering at client side. I mean, what if the each client receive a stream of multiplexed segments of different - different clients, from server. How we are able to assemble these different segments, corresponding to different clients, at client side to make a complete message, and display the whole message with the name of the sender of the message.

Hope now it will will be clear to you.

[i3839]

As it's a chat program anyway, the messages won't be that long, so you can just serialize on the server, and as server send only wholy received client messages. You can also chop big messages (e.g. files and other big stuff) into multiple smaller chunks and reassemble it together at the end. You shouldn't blindly send partially received messages to all clients, because then you get the problem you're talking about.

[myself_rajat]

ya i3839, I also thought of doing the same thing, that until I receive the whole message I will not send it back to the clients. Though I am not considering any message length limit at client side while sending. So that choping the message in to packet would be good. But As I am using TCP, So I just left it up to TCP.

[i3839]

TCP gives you one endless stream of data, and nothing more. If you wanted the protocol to packet kind of stuff then you should have used UDP. So with TCP you are more or less forced to use your own packet/message protocol on top of it.