Thread: Writing a "Protocol" - Stumped.

  1. #1
    Registered User
    Join Date
    Jan 2003

    Writing a "Protocol" - Stumped.


    been trying to figure out the best way to do this for a while and have tried the web but cant seem to find a definate answer.

    with a client / server scenario I need to create some kind of protocol for the two to speak the same language.

    lets say I have two clients and one server, both clients connected to the server and I need to just display movement with an up arrow key moving 1 sqaure up, down arrow key 1 square down etc with both clients being able to see what the other is doing. Ive adopted the idea of sending the data to the server and the server sends the clients the updates rather than client to client.

    Now i know FTP, etc use commands like STAT,PASS, etc etc. but is this data just sent in a string with a common deliminater and broken up server side ?

    I was considering having a struct on the server which holds all incoming data but my question is whats the most efficient way to break up the data coming in ? The idea of stripping a string of incoming data would seem too slow on a large scale ?

    So at the moment im looking at <userid>:<command>:<end of data marker> or something like that, sending in a string and stripping it on the server.. slow? bad idea? really sounds it but im stumped as to an alternative. I cant send data structures to be re-assembled can i ?

    Anyone have any pointers or suggestions where to start ?

    Thanks in Advance,


  2. #2
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    The edge of the known universe
    > So at the moment im looking at <userid>:<command>:<end of data marker>
    Yeah why not - seems good enough to me

    Quick guess-timate of what the bandwidth is
    20 bytes per message
    10 messages per second (how fast csn you press a key anyway?)
    -> 200 bytes per second per client of message traffic.

    It's certainly good enough for development and debugging, since printable strings are so easy to spot and check that they contain the right info.

    So long as you make a half-decent job of encapsulation, changing over to something more compact if need be.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  3. #3
    Registered User
    Join Date
    Jan 2003
    Thanks for the response.

    OK well i will stick with that method and see how I get on.

    Just a couple of questions.. When you say "changing over to something more compact if need be." what other methods are there ?

    I notice you have said it will be fine for debug and dev but as an end result what is the preferred method ? i.e multiplayers like quake, half life, etc would they process data received encapsulated in a long string?

    Thanks for comments


  4. #4
    mov.w #$1337,D0 Jeremy G's Avatar
    Join Date
    Nov 2001
    I was thinking, if your sending such a small bit of information (one square movement) why not compact as much as possible into a very small message that can be sent and dealt with quickly.
    Perhaps you can combine the user id with the movement command. Consider assigning id's by the 10's place iinstead of the one's. IE
    user id 10
    user id 20
    user id 30
    user id 100
    user id 110
    Then you can associate 9 simple commands to the ones place.
    1 = up, 2 = right, 3 = down, 4 = left, 5 = level up, 6 = level down etc.
    Then combine that information and send it to the server.
    Server would receive maybe 23. Seems a lot more compact and useful. I dunno just a possibility.
    (it should be realized my posts are all in a light hearted manner. And should not be taken offense to.)

  5. #5
    Registered User
    Join Date
    Jan 2003
    You can also use binary to squeze as much information as you can. Making simple structs will also make it easier to parse, just like if you were opening/reading a binary file. Bitfields are also cool, but binary operators are just as good.
    // sizeof(Message) = a nice even 8 bytes (the size of a single double)
    struct Message
       unsigned short id;
       unsigned char type;
       unsigned char flags;
             char key1;
             char key2;
          } keyboard;
             char buttons;
             char x;
             char y;
          } mouse;
             short x;
             short y;
          } update;
          // etc

  6. #6
    I would tokenize the input on the computer before sending it to the server. That way you can get it down to an "opcode" sort of thing. You can have different hex values for different commands. That way you'll only have to send one byte for the command, and the arguments.

    PS: That was all IMHO

  7. #7
    Carnivore ('-'v) Hunter2's Avatar
    Join Date
    May 2002
    Bitfields if you're really really trying to cut down message size... although TCP overhead would dwarf the message size anyways.
    struct Message
         unsigned char arrow : 2; //from 0 to 3; 4 arrow keys
         unsigned char id : 6; //allows 64 ID's
    One byte per message And about 9999 more bytes tacked on automatically for the TCP protocol header doojigger and whatever else might need tacking on.

    IMHO, don't bother trying to scrimp and save on message size like this when it's already so small.
    Last edited by Hunter2; 01-20-2004 at 08:55 PM.
    Just Google It. √

    (\ /)
    ( . .)
    c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.

  8. #8
    Registered User
    Join Date
    Jan 2003
    You can use UDP which only uses 8 bytes of header space (as opposed to the large TCP headers). They are also faster than TCP packets but they tend to arrive out of order or might not arrive at all. So what I'd do is have two networking parts. A UDP section would send immediate data such as movements or keypresses etc. Important stuff should be sent by a TCP section like scores, world updates, etc.

    A simple UDP packet has to include a timestamp so that the reciever knows in which frame/game time the data packet corresponds to and whether it should be counted or not. A base UDP packet is 28 bytes (IP protocol) + 8 bytes (UDP protocol) = 36 bytes + any data you have attached on it (remember a timestamp).

    In addition, try sticking one or more packets together with the same timestamp. That attached more data and less overhead. However, if you lose the package, you lose more data.

    All stuff to think about!

  9. #9
    Registered User
    Join Date
    Jan 2003
    Thanks for all responses, most insightful

    Theres a few ideas to play around with here, ill experiment with them all and see what works best for what I need to do.

    Thank you


Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 2
    Last Post: 05-20-2008, 08:57 AM
  2. Very slow file writing of 'fwrite' function in C
    By scho in forum C Programming
    Replies: 6
    Last Post: 08-03-2006, 02:16 PM
  3. Folding@Home Cboard team?
    By jverkoey in forum A Brief History of
    Replies: 398
    Last Post: 10-11-2005, 08:44 AM
  4. help! fifo read problem
    By judoman in forum C Programming
    Replies: 1
    Last Post: 08-16-2004, 09:19 AM
  5. The Art of Writing Comments :: Software Engineering
    By kuphryn in forum C++ Programming
    Replies: 15
    Last Post: 11-23-2002, 04:18 PM
Website Security Test