C#与Java通过protobuf进行网络通信过程中遇到的问题
发表于2018-10-17
关于protobuf的概念这里就介绍了,使用protobuf的有点有很多,网上这方面的资料也不少。为了测试这个玩意,随便弄了一个客户端,拿C#写了一个简单的控制台程序请求服务端,服务端拿java的HttpServer做了一个简单的响应客户端请求。
Protobuf用的2.6.1版本。
客户端下载地址:https://github.com/andyqingliu/TestHttpClient.git
服务端下载地址:https://github.com/andyqingliu/TestHttpServer.git
(Note: 写了很多测试代码,为了测试方便,所以代码比较混乱。)
记录一些重要的信息备忘,顺便梳理一下当时使用C#与Java通过protobuf进行网络通信过程思路和遇到的几个重要的问题及解决方案。
1、客户端数据准备
a.用C#自带的WebClient类异步发送数据
WebClient wc = new WebClient();
wc.Headers.Add("Content-Type", "application/x-www-form-urlencoded");
wc.Encoding = Encoding.UTF8;
wc.UploadDataCompleted += new UploadDataCompletedEventHandler(OnUploadDataCompleted);
wc.UploadDataAsync(uri, "POST", buff);
b.利用MemoryStream类来存放要发送给服务端的字节流。
原来MemoryStream有ToArray的方法直接把字节流转换为字节数组。刚开始自己写读取流方法一直有问题,写不了数据,后来请教同事发现有现成的方法,绕了一大圈。同样,MemoryStream也有字节数组的构造函数,很是方便。
c.客户端协议如下表:
客户端协议格式
协议第一部分 | 协议第二部分 | 协议第三部分 |
4字节的int,标记协议长度 | 2字节的short,标记协议个数 | N字节的协议内容 |
其实这里更合理的组织方式是第一部分与第二部分对调。这里仅仅测试,写的比较随意。此表只是为了说清楚协议的组织方式。通过与同事讨论,觉得以如下方式组织协议更为合理。
合理的协议组织方式
协议包头 | 协议长度 | 协议内容 | 协议长度 | 协议内容 |
2字节short | 4字节int | N字节内容 | 4字节int | N字节内容 |
d.Protobuf的C#Api提供了对象的序列化与反序列化方法如下:
ProtoBuf.Serializer.Serialize(stream, T); ProtoBuf.Serializer.Deserialize<T>(stream);
2、服务端数据准备
a.利用HttpServer来创建服务端监听。
final InetSocketAddress sa = new InetSocketAddress(8888); HttpServer server = null; try { server = HttpServer.create(sa, 0); } catch (IOException e) { e.printStackTrace(); } server.createContext("/",new MyResponseHandler()); server.setExecutor(null); server.start();
b.通过MyResponseHandler类的handle方法的httpExchange参数的getRequestBody方法来获取客户端的请求的流信息,并进行解析成对应的对象。
c.服务端解析协议方式对应客户端协议格式。
d.Java对Protobuf字节数组处理方式比较蛋疼。
每个协议对象都有一个parseFrom方法来序列化。这一点比较方便,也是蛋疼的地方。
反序列化则是每个对象都会生成一个Protobuf的类型,比较麻烦。
Person.Builder person = Person.newBuilder(); person.setValue(12345); C2S_GetFriendList_message.Builder build = C2S_GetFriendList_message.newBuilder(); build.setResult(54321); build.setP(person); C2S_GetFriendList_message friendList_message = build.build();
一段空白之后遇到了传说中在网络传输过程中的大小端问题。个人理解是这样的:网络协议规定低内存地址存放高字节,高内存地址存放低字节。不同处理器处理字节的方式各有不同,X86处理器以小端方式处理字节序列,发送字节数组,即低内存地址存放低字节,高内存地址存放高字节。而java虚拟机则以大端的顺序来存放。即低内存地址存放高字节,高内存地址存放高字节。
举例说明,比如有一个int = 129,其转换为字节数组为{129,0,0,0},一个大小为4的字节数组,假如有一段内存地址,从左到右内存地址值变大,字节顺序是这样:
字节序列
0x0643E690 | 0x0643E691 | 0x0643E692 | 0x0643E693 |
129 | 0 | 0 | 0 |
对应的二进制为 00000000 00000000 00000000 10000001.十进制为129.
而对于java虚拟机,则会把上述字节数组翻译为“大端”,其在内存中的字节序列如下:
Java虚拟机内存字节序
0x0643E690 | 0x0643E691 | 0x0643E692 | 0x0643E693 |
0 | 0 | 0 | -127 |
对应的二进制为?10000001 00000000 00000000 00000000. 由于Java没有无符号数,最高位代表符号位,这里的二进制最高位为1,代表负数,而Java虚拟机用补码表示负数,所以此数的绝对值代表的二进制为:01111111 00000000 00000000 00000000.加上符号,转换为十进制为-2130706432。
于是,如果没有对大小端进行统一,就会出现发送方的数据与接收方的数据不一致的问题。发送129,收到的却是-2130706432。
解决办法是:需要在客户端进行转换,可以用?IPAddress.HostToNetworkOrder把需要发送的字节序列转换为网络字节序列,即转换为大端序列。代码如下:
int testInt = 129; byte[] ints = System.BitConverter.GetBytes(IPAddress.HostToNetworkOrder(testInt));
然后在服务端也进行转换,转换为大端序列,如下:
ByteBuffer bbBuffer = ByteBuffer.wrap(bs);
bbBuffer.order(ByteOrder.BIG_ENDIAN);
这样就能保证发送方与接收方都采用大端的方式,避免得到不想要的结果。
可能有些同学会问一个问题,为什么c#发送的字节数组是{129,0,0,0},而到了java端变成了{-127,0,0,0},这是因为c#的byte是无符号的8位字节,而java端的byte是有符号的,对于c#,byte的取值范围是(0,255),而Java端的byte取值范围是(-128,127),129的二进制为10000001 ,对于c#而言,对应的十进制是129,而对于java而言,最高位为1,表示负数,负数用补码来表示,所以其绝对值的二进制为011111111,十进制为127,所以java端认为这个值是-127.
来自:https://blog.csdn.net/andyqingliu/article/details/53997021