I have been following Beej's Networking Tutorial 2.3.1 at ( http://www.ecst.csuchico.edu/~beej/guide/net/html/ ). I am currently using his last example on the "Synchronous I/O Multiplexing" selectserver.c but changed it to handle unconnected datagram sockets.

Currently my server just sends a "1" character to the client and the client responds with a double[32][4]. This is working fine. What am interested in is expanding the protocol to include other instructions. However Beej didn't cover any protocol programming. So am wondering if anyone knows any good tutorials on protocol programming. Or even a good protocol library/suite that can be easily used with Beej's selectserver.c.

Below is a protocol idea I have in mind for my application of a Real-Time Linux Cluster Monitor:

Server Commands:
"C" - Retrieve Group Of Hosts Processor Statistics
"M" - Retrieve Group Of Hosts Memory Info
"A" - Retrieve Both Group Of Hosts Processor & Memory
"X" - Shutdown Client Program
"G:1:2:3:4:5" - Change Group Of Hosts To Monitor
(Should I send integers since they're smaller than characters?)

Client Replies:
"C", double[32][4] // User, System, Nice, Idle
"M", double[32][8] // Used, Shared, Buffers, Cache, Swap Used, Load Avg (1min, 5min 15min)
(Is this the best way? Client sends a character then a double array? Or should I packaged them up in a structure? Is it possible to send a structure? Since we're sending 32x8 doubles would compression help lowering the network over-head? Is the character id reply unnessary? Would omitting the character id in the reply be okay?)
"A" struct {double[32][4]; double[32][8];}
"X"

Umm, integers are larger than characters. Now, the string representation of a number may well be larger than an integer version (at values>=10,000).

On another note... be very careful with all this. Passing structs and the like over the network requires that both ends have the structs compiled in EXACTLY the same way. (Same order, same sizes, the works).

Depending on compilation options, some structs may look differently on each end, unless you're careful to use the same compiler version and options. In other words: expand the data manually and then re-read it manually.

Are you going to be running over TCP or UDP? That affects the design of your protocol, of course.

I would not use compression for situations you've described above. Compression does not work well for small amounts of data and has a tendency to use more CPU than its worth. If you're running a cluster, they'll all need to be connected via some sort of decent bandwidth interconnect, so you shouldn't be worried about a ~256 byte message.