Question

I’m trying to design a server/client architecture, and I’d wanted to ping you guys to determine the best way to represent and parse different types of packets. Each packet type would need to be parsed differently. Below represents the type of packets I’d see.

[*packet_type*][length][variable length data]
*packet_type* describes the type of packet we're sending (client login, server returning authentication, data, etc)
length describes how much data to read
variable length data contains the info to be sent. it will be specialized based on the packet_type. the data will be variable regardless of 

I’ve looked into the tcphdr struct, and I think I’d be able to use a similar type of header for that to represent the *packet_type* and length. Then, I would use a String to represent the data.

public class Packet {
    public enum PKT_TYPE {
            CL_REGISTER,
            CL_LOGIN,
            SRV_AUTH,
            SRV_GAME_INFO,
    }

    PKT_TYPE _packet_type;
    int _length;
    String _data;
}

Now that there is a common base, I figured that I could implement classes and send/receive methods for each *packet_type*. However, I feel like this isn’t very scalable and it would be very hard to maintain. An (rough, pseudo) example of this would be

public class Packet {
...
   public class Pkt_CL_LOGIN extends Packet {
       String _loginname;
       String _password;

       public boolean send() {
           //socket.write(CL_LOGIN, length, _loginname+_password);
       }
       public Pkt_CL_LOGIN parse(String data) {
           //removed header already, so first byte will be data
           //extract login + password
           _loginname = login;
           _password = password;
           return this;
       }
   }
   public Packet receive() {
       //read from socket
       //parse header for packet_type
       switch (packet_type)
           case CL_LOGIN:
               return (new Pkt_CL_LOGIN()).parse(data);
   }
}

Can anyone give me some recommendations on how to implement this differently? I’m not quite sure if there is one, but maybe someone with more experience can give me some insight (such as how they do it in multiplayer games, etc)

Thanks!

Answer 1

I’m currently making a multi-threaded C++ chat server using Protocol Buffers for the actual protocol implementation. Point is, I think you should use them: they give you a pretty interface to each packet you require, they can be used in a number of languages (C++, Java and Python just to start, I think there’s some Ruby interface to them as well) and they allow you to create versatile protocols without much effort as they take away the serialization problem and the need to write your own class for each packet. Also, there’s a specific “lite” version for mobile devices (which might come in handy if you’re coding for Android).

Regarding the packets, there’s two ways that I know of for keeping track of when a packet ends: the first one being having fixed length packets, and the second one sending the length before actually sending the packet. The same applies to the packet type. In case you don’t have many packet types, you could just use a single unsigned char (now, this is C++, but I guess there should be some way to do the same in Java) to represent it, which would give you exactly 255 packet types (more than needed, if you ask me).

In the case of my server, I actually worked it out sending a fixed-length header which contains packet length and type (both are fixed length uint32), which is then parsed, and then the socket is read again to retrieve the information, which is then parsed accordingly and sent to its proper handler within the client handler. I think the approach is pretty nice, except for the fact that well… I’m using some extra memory for nothing (packet type is too big)…

As an example for protocol buffers, your .proto file could look a little something like this:

message Header {
    required fixed32 length = 1;
    required fixed32 type = 2; // Note: don't use an enum here, as the values are serialized to varint, which simply kills your fixedness.
}

message Login {
    required string nickname = 1;
    required string password = 2;
}

enum ErrorType {
    BAD_HEADER = 0;
    WRONG_PASSWORD = 1;
}

message Error {
    required ErrorType type = 1;
    optional string message = 2;
}