Writing a "Protocol" - Stumped.

[mrpickle]

hello,

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,

mrpickle.

[Salem]

> 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.

[mrpickle]

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

mrpickle.

[Jeremy G]

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
etc.
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.

[Speedy5]

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;
   union
   {
      struct
      {
         char key1;
         char key2;
      } keyboard;
      struct
      {
         char buttons;
         char x;
         char y;
      } mouse;
      struct
      {
         short x;
         short y;
      } update;
      // etc
   };
};

[bludstayne]

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

[Hunter2]

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.

[Speedy5]

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!

[mrpickle]

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

mrpickle.