最近要做socket，自己拟了个封包协议，帮忙看看可行性

Question

每个完整的封包由三个部分组成：封包头 + 数据（可选） + 文件流（可选）封包头为一个结构类型，总长度为 15 字节PacketFlag: Char        // 1字节。用字符“#”表示封包头的开始
Action: WORD           // 2字节。用于描述该封包的行为
XmlSize: DWORD       // 4字节。XML文件的大小（不含封包头）
FilesSize: ULONG64   // 8字节。表示所有传输文件大小的总和。仅仅用于传输文件的封包封包头后接着就是一个XML文件流，包头中XmlSize表示其大小XML流后就是传输的文件流（可通过封包头中的Action或FilesSize判断是不是一个传输文件的封包）
如果是传输文件的封包，则XML流结束后接着就是文件流，文件的相关信息在XML文件中描述，要注意顺序要与XML中对应

Answer 1

自己觉得 PacketFlag 这个是多余的

Answer 2

PacketFlag有意义，可以效验出错的数据包
感觉应用的重点在传文件
加一个压缩标记就最好不过了我的应用相对数据包小，数量多，因此我采用4字节数据包头，这个DWORD，0,31位必须为1，也就是$80000001
30位为压缩位，29位为加密位，剩下的28位最大为$FFFFFFF来表示数据包的大小，最大255M，而这个数据包的行为，在网络通讯层，不会去理会，网络通讯层用来负责传达数据和接收完整的数据，这个层面作的事情是，用户提交发送数据请求时，首先整理包头（我这里是4字节），需要压缩的就压缩，需要加密的就加密，然后连同包头的4字节一起发送出去，当接收的时候，首先分析这4字节并效验，然后取出包大小相等的字节，有加密标记就解密，有压缩标记就解压缩，然后把得到的数据通知用户层，而用户层不用关心数据包头，压缩，加密什么的了，只管调用发送函数和相应接收事件就可以了。希望能有所帮助。

Answer 3

仔细想了想，以传文件为主的应用，不能等数据到齐了才通知用户层，而应该是
OnPackctBegin,OnPacketData,OnPacketEnd;应该是这样才好，感觉你是想一次传递多个文件，而不是一次一个文件，因此用了XML在中间，这种情况，不是很好处理断点续传哦，还是单个单个地传好一点。断点续传就得加一个Offset头来表示位置，最好再加一个以及BeforeCRC32来表示已传部分的CRC32值，以保证文件的准确性.。。

Answer 4

谢谢你的热心回复。经你一说，的确是这样，一个个传比较好
断点续传复杂了点，暂时不考虑了另外一个是，如果再传输文件数据时，有其他操作进行，这时是处于阻塞状态吧？要等文件传输完成了才能响应
比如A给B传文件，在数据传输时，A又进行了其他操作，由于B还在接受文件数据，不能及时响应后来的命令吧

Answer 5

如果文件比较大的话，不是客户端对客户端的方式，个人推荐使用FTP的方式

Answer 6

是的，这是一对一，如果要考虑多通道，在数据包头上加上通道号，把数据包分割小一些，以便更快相应新的请求，
发送是循环通道进行发送，
在接收端上带上通道号调用事件，根据通道号整理数据FTP方式被动方式的模式是这样：首先告诉FTP我要传文件了，FTP服务器返回传文件的IP及Port，客户端连上这个IP:Port进行文件传送，所以对主通讯不会阻塞，如果是主动模式就会阻塞主通讯。