这样的消息头设计合适吗？

夜荷

struct TMsgHead
{
        int        userID;                                                       
        unsigned char type;        //消息的基础类型        一级编号        用于分大类        Byte
        unsigned char ID;        //消息的类型        二级编号        用于分细节
        int len;                //整个消息的长度，包括消息头和消息内容
};

例如一个购买道具的消息
type = TradeMsg
ID    = Buy

然后在TMsgHead结构体后面跟一个
struct buyMsqReq
{
int goodsID;
int num;
}

一个结构体，在里面定义购买的货物的编号以及数量。
在数据发送的时候，将这两个结构体的内容copy在一起，加上消息的结尾标志发送给服务器。

tarkey

考虑下对齐吧,把int len换成u16 len就可以做到32bits对齐,另外id没必要用带符号的吧.
另外没必要给消息加结尾标记.

夜荷

tarkey 你的建议很好，len可以换为u16，做到32bit对齐
消息头的 type 和 id 都是无符号，TradeMsg，Buy 等消息都是用#define来定义，我想这样作应该没有什么问题。
至于消息结尾的标记主要是在socket通讯的时候，能够从数据包里准确的切割出消息。

对了，不知道 tarkey 你对服务器集群有没有了解，我在网上很少看到有关集群的介绍

tarkey

切出消息只要消息头和长度就够了

夜荷

如果这样的话，万一数据包里其中某一个包发生问题，那不会造成后面的包都会接收错误？

lwevil

要的，可以考虑对齐

aear

首先是TCP不会出错，UDP也不会产生包错误，最多数据丢失。
其次，假设会出错，如果出错在结尾的数据结构上，怎么办？ 所以结尾的数据结构是没必要的。
最后，所有数据包是在IP layer 和 data link layer 都有做checksum，即使你在transport layer进行数据对其，到IP layer 和data link layer分包(TCP会分包，UDP是做fragmentation)或者分frame(data link layer)的时候，完全是操作系统决定的，到时候又不对齐。如果是为了提高checksum的效率，也无必要，因为现在的checksum都是网卡硬件做的，完全无速度上的影响。

但是数据头是有必要对齐的，这样在application layer处理速度更快。还有最好加上个消息头识别码，比如 UINT32 ProtocolID = 0xA0EFC755 ,在处理UDP包里很有用。

liam

你的消息分两层的好处在哪里?
这种好处与付出的代价衡量过吗?
struct TMsgHead
{
u32 userID; //连接号
u16 ID; //消息的类型
u16 len; //整个消息的长度，包括消息头和消息内容
}

这里len可要可不要

filx

你的数据头大了点.而且没对齐.

typedef struct tagPACKET_HEADER{
     DWORD:8         Type;
     DWORD:8         Flag;
     DWORD:16       Size;
};