字节流通信协议

今日学习了字节流通信协议，知道了它的基本原理：任何的信息在网线中都是以字节的形式传递的，要解析这些字节，把它们“恢复原貌”展现在用户面前，于是就有了通信协议，而字节流通信协议则是其中的一种形式。

 

字节流通信协议的形式：

总长度	信息类型	人名的长度	人名内容	信息的长度
int	byte	byte	int	int
总长度	信息类型	文件名长度	文件名	文件内容
int	byte	byte	int	int

 

 

    还可以把这些协议定得很长很长，协议的形式是自己定的，就有点像“中文解释运动”。比如在说明一件事的时候，你要先说那是一件什么事，那件事怎么样，然后再说明有些什么其他的特点，当然这些特点需要一一细说，然后剩下的就只有“总而言之”了。

    换成了在网线里面，“中文解释运动”的语言全部换成byte了，而用一连串的byte值，也不知道怎么说明那些信息有什么特点才好，起码一堆的byte值你用肉眼是分辨不出消息有什么特点的，只好从信息的长度下手了（大概在网线里只剩下这么一个特点了吧！= =+），首先用一个int描述人家（指发送的信息）有多长，然后用一个byte值描述人家是什么类型的人物，然后如果消息是要发送的信息的话，就先把发送的人名的长度用一个byte存起来，然后用一堆的byte来把发送的人们存储起来，这里我是这么想的：就感觉是把一个词先存到前面了，后面一堆话来解释前面的词是什么，有什么含义。然后把另一个词存入，然后一大堆的话来解释它……如此往复地进行下去，到最后剩下的东西“总而言之”一下就OK了。协议的最后不是把消息的内容全部都用一个“巨型”byte存储了吗？而在这样巨型存储之前也没有把消息的长度先用一个byte存储，因为总特点-分特点*n=“寥寥无几的特点的总而言之”。就比如说上面的发送信息的那个例子：总长度=4（总长度所占的int的位数）+1（信息类型所占byte的一个位）+1（人名的长度所占的一个byte）+NameLength（人名的长度）+MessageLength（发送的信息长度），就是这样了。

 

    特别注意：发送文件的时候，一定要先把文件读入字节流中（吾辈怎么能忘了这么关键的一步呢！！！），要不然就会出现我这种bug状况，文件发不过去。总长度一定不要搞得乱七八糟，不然很会发生紊乱的，客户端的协议要和服务器的一致。这样才能把文件发送过去。**说：“黑客就是要高精度地解析字节。”好吧！注定我成不了黑客，那是些外星人，大概他们的语言可以表现成为byte。一黑客说：“10 1 1 2 6”，另一黑客答：“12 1 1 1 9”……= =+（老大，二进制存储啊！你别装作不知道计算机只认识0、1啊！= =+）

 

    代码就不共享了，现在还存在bug，能够发送信息过去，但是仅限于我在程序中预定好的。虽然我在生活中比较强势，但是我不希望代码跟我一样强势啊！每次只发送“xyz”我会很郁闷的……继续修改代码去，我要提前适应程序猿的生活。

 

<!--EndFragment-->