OOBInline属性为false，server接收了client通过sendUrgentData 发送的紧急数据包

标签：socket   java   oobinline   sendurgentdata   

前几天前置上线遇到一问题，大体情况是这样有一个加密服务，对外暴露tcp通讯接口，client端建立连接池，启N个连接（长连接），每次报文通讯之前先通过client端的sendUrgentData(0XFF)方法发送心跳包，用以检测信路是否正常.然后计算待发送报文的长度，将其转换成byte拼在发送报文前面（3字节长）发送报文，服务端read3字节报文并将其转换成报文长度，再根据该长度read定长的报文。测试环境OK没啥问题，上线时出问题了，每次读取的报文长度计算出来为16711680，最后发现是因为server端将client通过sendUrgentData(0xFF)发送的心跳包给当作报文处理了。

计算报文长度方法,传入字节数组，返回报文长度。

 public static int toInt(byte[] bRefArr) {
  int iOutcome = 0;
  byte bLoop;
  for (int i = bRefArr.length - 1, x = 0; i >= 0; i--, x++) {
   bLoop = bRefArr[x];
   iOutcome += (bLoop & 0xFF) << (8 * i);
  }
  return iOutcome;
 }

查看java6API描述

socket类有一个OOBInline属性，

   /*
    * 启用/禁用 OOBINLINE（TCP 紧急数据的接收者） 默认情况下，此选项是禁用的，即在套接字上接收的 TCP 紧急数据被静默丢弃。
    * 如果用户希望接收到紧急数据，则必须启用此选项。启用时，可以将紧急数据内嵌在普通数据中接收
    * on - true 表示启用 OOBINLINE；false 表示禁用。
   */

那么说生产环境该属性为true?导致了server接收了 client.sendUrgentData(0xFF)的紧急数据包？

不是的，经证实该属性在生产环境通过日志输出为false。那么是什么原因导致了这个问题的发生呢？

我只能认为是因为生产网络环境导致，网络层面对socket通讯包做了封装，改变了sendUrgentData发送的报文方式？？？

OOBInline属性为false，server接收了client通过sendUrgentData 发送的紧急数据包

标签：socket   java   oobinline   sendurgentdata   

原文地址：http://blog.csdn.net/lingjun_yang/article/details/40780249