Page 2 - Chat Server Version 0.1

Agh! that's some socket bug I havn't been able to fix. What's happening is the client is receiving two messages from the server at once and sticking them in the same input string. So say it sends 'CON:mark' and then 'USERLIST' right after, the client will end up concatenating them to 'CON:markUSERLIST'. It sends that off to the parser which gets rid of 'CON:' and what it left is 'markUSERLIST'. I have a hard time reproducing it on my Mac, sometimes it ends up happening when a 5th or 6th client connects. Any ideas on how to keep it from doing this? Is there anyway to tell recv() where the end of one message is? I've heard something with newlines when it comes to buffered input.

No ideas? Any socket gurus?

Xx,
Not sure how else to do it but what about constructing a header and putting that at the front of each message? The header will start with a sequence to identify it, a start of message pointer and length of message.


Then all you do is read the first 6 bytes, check them, read (len -6) characters, split the remaining head from the actual message and process the message. I've included a message start pointer to allow for a variable length of header - that way you can expand your protocol in the future.
You could consider adding a "type" character in the header to indicate what the contents of the packet are e.g. message or control.

Grim

By knowing the size of the "packet" you can ignore any rubbish in between and by specifying the length up-front you can include any "control" characters you like in the message.

I think you need something like this so that your receiver does not rely on it's previous receive state to accurately decode the subsequent messages. To get more sophisticated, include a simple checksum in the header so that during a recovery when you scan the incoming data for the start of packet you can be sure that the sequence really was the start of packet.

Grim

Hmm it sounds like it will take quite a bit of work to implement this, but it's definitly something I will look into. Thanks.

To keep it simple and trial it you can just include the message length as the first byte and limit messages to max 255 characters. You only have a one byte header. (So maximum packet size is 256)

But that builds in limits and does assume that every packet is received correctly (i.e. there is never a bug in the sender program)

I'll probably take the first idea for the experience. Thanks for your help .