关于如何自己设计一个基于TCP的协议

gawk

原帖由 chrisyan 于 2008-8-27 10:02 发表

多谢，我知道现在就是设计一个协议，来保证server和client之间的传输。
其实我还是有点疑问，像你所说的 ”同步码[4个字节的1]“ 这个四个连续的1也有可能出现在我的数据当中啊，因为我传的是二进制数据，不 ...

如果想这样设计，建议你看看电力系统上的CDT规约，比较简单
你说的东西基本上都包括

ideawu

可以学习FTP, 开一条数据通道.

山外山

struct protocol
{
int magic;
int bControl;//控制还是内容
int crc;//传输数据(data)的校验码
int data_len;//data的长度
char data[0];
};

根据bControl决定是数据还是控制。switch...case处理

然后read(sockfd,(struct protocol*)&prot,sizeof(protocol)),把头部读出来,判断prot.data_len.
最后read(sockfd,buf,data_len);
解析这个buf就可以了

看看是你要的不？

[ 本帖最后由 山外山 于 2008-8-27 14:33 编辑 ]

chrisyan

多谢以上的各位兄弟，我明白一些了，还要再深入看一下
多谢gawk兄，我来看看CDT规约

wuqing

原帖由 chrisyan 于 2008-8-27 10:02 发表

多谢，我知道现在就是设计一个协议，来保证server和client之间的传输。
其实我还是有点疑问，像你所说的 ”同步码[4个字节的1]“ 这个四个连续的1也有可能出现在我的数据当中啊，因为我传的是二进制数据，不是没有这个可能。
因为控制和数据在同一个链接上传输，这个就比较烦。
我所理解的gawk兄弟的意思是从一开始读的信息就是“操作代码+数据长度+数据”，这一次的传输长度就是 4（暂定操作码为一个int） + 4(暂定数据长度为一个int) + 数据长度,那么读完这么长的数据，再读4字节就是下一个操作码，然后再读数据长度，然后是数据，这样的话我都是根据长度来区分，不用去对所有的传输过来的数据进行分析，也就不用对传输数据内的可能出现的操作码进行转义。

你能不能再和我仔细说说？因为这个细节很重要，如果有一点地方我想不明白，我也就不会用这种方法去实现了。
...

你的疑问结合你的需求就可以轻松解决。
我说的“同步码[4个字节的1]”总是一种假设，不是说一定能用，也不是说一定要用。结合你的数据，肯定不能用在你的传输的数据中会出现的内容作为同步码。

良好的协议需要考虑充分才能设计出来

nicle

简化一下http header协议我想就可以了, 比如:

1. 
   
2. client->server:
   
3. 
   
4. POST\r\n
   
5. HASH:xxxxx-xxx-xxxxx\r\n
   
6. CONTENT-LENGTH:100\r\n
   
7. \r\n
   
8. ......Binary DATA.......
   
9. 
   
10. server->client:
    
11. 
    
12. 200\r\n
    
13. RESULT:xxxxxxx\r\n
    

复制代码

client在请求的时候, 在binary数据前附加一个header信息, 一边第一行告诉server我要提交数据了, 第二行是binary数据的hash值,这个hash值随便你用什么实现, crc/md5/sha1都可以, 接着是binary的长度, 在两个 \r\n后就是真正的数据了.

server 在收到client请求后,首先parse client的header, 看第一行是不是POST动作, 如果是继续解析其他header信息, 和读取数据.
server在处理完后, 开始回应client, 同样先组织一个header, 第一行是状态值, 一般200表示成功, 你还可以定义其他值,表示不同的情况. 如果成功的话, RESULT这个字段后面就跟结果.接着发送给client, client会从header中读取结果.

benjiam

原帖由 nicle 于 2008-8-28 16:34 发表
简化一下http header协议我想就可以了, 比如:

client->server:

POST\r\n
HASHxxxx-xxx-xxxxx\r\n
CONTENT-LENGTH:100\r\n
\r\n
......Binary DATA.......

server->client:

200\r\n
RESULT ...

  这种协议其实是最差的， 非常的差。 如果你写一下解析器就知道了。考虑一下 粘包 和解析。看一下apache 罗里啰唆的写了那么多，是为什么 你就知道 这种协议
除了容易读，效率很烂

[ 本帖最后由 benjiam 于 2008-8-28 16:53 编辑 ]

duanjigang

有必要么？其实平时自己规定的数据格式，结构体，如果再用TCP协议，已经算是基于TCP的简单协议了

nicle

原帖由 benjiam 于 2008-8-28 16:52 发表



  这种协议其实是最差的， 非常的差。 如果你写一下解析器就知道了。考虑一下 粘包 和解析。看一下apache 罗里啰唆的写了那么多，是为什么 你就知道 这种协议
除了容易读，效率很烂

我正好写过类似的协议, 对于这样简单的协议, parser很好写出来的. 你说所的 apache里边的parse, 我觉得那是http协议相对复杂点, 而且有http1.0/1.1它需要考虑, 罗嗦点没有办法.
如果说效率很烂的话, 我想http不会到现在还是web的根基. 而且这样写的话, 不会有平台依赖的问题.

[ 本帖最后由 nicle 于 2008-8-28 17:30 编辑 ]

gawk

原帖由 nicle 于 2008-8-28 17:29 发表


我正好写过类似的协议, 对于这样简单的协议, parser很好写出来的. 你说所的 apache里边的parse, 我觉得那是http协议相对复杂点, 而且有http1.0/1.1它需要考虑, 罗嗦点没有办法.
如果说效率很烂的话, 我想h ...

协议设计的好，平台不是问题