Page 2 of 2 First 12
  • Jump to page:
    #16
  1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2003
    Posts
    217
    Rep Power
    0
    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.
    Last edited by XxChris; March 14th, 2004 at 04:41 PM.
  2. #17
  3. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2003
    Posts
    217
    Rep Power
    0
    No ideas? Any socket gurus?
  4. #18
  5. Mini me.
    Devshed Novice (500 - 999 posts)

    Join Date
    Nov 2003
    Location
    Cambridge, UK
    Posts
    783
    Rep Power
    14
    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.

    Code:
    Characters in message block:
    0------2-----------4-------- 6---n--------------- n+len
    --------------------------------------------------------
    |Header|Msg Start=n| Msg Len|..... |Actual message......|
    --------------------------------------------------------
    where n is actually the end of header. 
    The header start sequence could be one or two characters like !#.
    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
    Last edited by Grim Archon; March 16th, 2004 at 03:02 AM. Reason: Spelt my name wrong:D
  6. #19
  7. Mini me.
    Devshed Novice (500 - 999 posts)

    Join Date
    Nov 2003
    Location
    Cambridge, UK
    Posts
    783
    Rep Power
    14
    Originally Posted by Grim Archon
    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.

    Code:
    Characters in message block:
    0------2-----------4-------- 6---n--------------- n+len
    --------------------------------------------------------
    |Header|Msg Start=n| Msg Len|..... |Actual message......|
    --------------------------------------------------------
    where n is actually the end of header. 
    The header start sequence could be one or two characters like !#.
    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
  8. #20
  9. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2003
    Posts
    217
    Rep Power
    0
    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.
  10. #21
  11. Mini me.
    Devshed Novice (500 - 999 posts)

    Join Date
    Nov 2003
    Location
    Cambridge, UK
    Posts
    783
    Rep Power
    14
    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)
  12. #22
  13. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2003
    Posts
    217
    Rep Power
    0
    I'll probably take the first idea for the experience. Thanks for your help .
Page 2 of 2 First 12
  • Jump to page:

IMN logo majestic logo threadwatch logo seochat tools logo