OOBInline属性为false,server接收了client通过sendUrgentData 发送的紧急数据包
来源:互联网 发布:无主之地2人工智能 编辑:程序博客网 时间:2024/06/05 17:11
前几天前置上线遇到一问题,大体情况是这样有一个加密服务,对外暴露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 发送的紧急数据包
- 通过UDP发送和接收数据包
- qt socket通信中接收client发送是十六进制数据包
- 发送/接收数据包与发送/接收字节的区别.
- 网卡接收和发送数据包的过程
- 网卡接收和发送数据包的过程
- 网卡接收和发送数据包的过程
- 网卡接收和发送数据包的过程
- 网卡驱动的数据包发送接收
- 网卡接收和发送数据包的过程
- Qt下通过packet库实现ARP数据包的发送和接收
- 如何用socket.sendUrgentData()发送紧急数据(一般用不到,了解)
- GCM 发送接收消息 Message Client Server 服务器端,客户端
- GCM 发送接收消息 Message Client Server 服务器端,客户端
- nginx向client发送数据包
- 网络数据包发送接收全过程
- 网络数据包发送接收全过程
- 网卡如何发送、接收数据包
- Android布局注意事项
- Win7实现内录声音
- 什么是大牛,我彻底服了,大牛讲解信号与系统 .
- 在路上
- sublime text快捷键MyEclipse风格
- OOBInline属性为false,server接收了client通过sendUrgentData 发送的紧急数据包
- 线性时间冰山查询算法(Linear-time Iceberg Query Algorithm )
- java 程序包不存在
- Cpp 调用sql server 存储过程时不返回output参数解决办法
- QtQuick程序在ubuntu测试机上运行提示module "QtQuick.Controls" is not installed
- java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.reflect.ParameterizedType
- Python之lambda
- 《从0开始学产品策划》第一期:认清项目本质
- 浅谈算法和数据结构(11):哈希表