OOBInline属性为false,server接收了client通过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发送的报文方式???

时间: 2024-10-09 07:53:15

OOBInline属性为false,server接收了client通过sendUrgentData 发送的紧急数据包的相关文章

swoole深入学习 2. tcp Server和tcp Client

这节来学习Swoole最基础的Server和Client.会通过创建一个tcp Server来讲解. server <?php class Server { private $serv; public function __construct() { $this->serv = new Swoole\Server('127.0.0.1', 9501); //当启动一个Swoole应用时,一共会创建2 + n + m个进程,2为一个Master进程和一个Manager进程,其中n为Worker进

【转载】串口中怎样接收一个完整数据包的解析

这里以串口作为传输媒介,介绍下怎样来发送接收一个完整的数据包.过程涉及到封包与解包.设计一个良好的包传输机制很有利于数据传输的稳定性以及正确性.串口只是一种传输媒介,这种包机制同时也可以用于SPI,I2C的总线下的数据传输.在单片机通信系统(多机通信以及PC与单片机通信)中,是很常见的问题. 一.根据帧头帧尾或者帧长检测一个数据帧 1.帧头+数据+校验+帧尾 这是一个典型的方案,但是对帧头与帧尾在设计的时候都要注意,也就是说帧头.帧尾不能在所传输的数据域中出现,一旦出现可能就被误判.如果用中断来

Linux内核中网络数据包的接收-第二部分 select/poll/epoll

和前面文章的第一部分一样,这些文字是为了帮别人或者自己理清思路的,而不是所谓的源码分析,想分析源码的,还是直接debug源码最好,看任何文档以及书都是下策.因此这类帮人理清思路的文章尽可能的记成流水的方式,尽可能的简单明了. Linux 2.6+内核的wakeup callback机制 Linux 内核通过睡眠队列来组织所有等待某个事件的task,而wakeup机制则可以异步唤醒整个睡眠队列上的task,每一个睡眠队列上的节点都拥有一个 callback,wakeup逻辑在唤醒睡眠队列时,会遍历

linux 内核网络数据包接收流程

转:https://segmentfault.com/a/1190000008836467 本文将介绍在Linux系统中,数据包是如何一步一步从网卡传到进程手中的. 如果英文没有问题,强烈建议阅读后面参考里的两篇文章,里面介绍的更详细. 本文只讨论以太网的物理网卡,不涉及虚拟设备,并且以一个UDP包的接收过程作为示例. 本示例里列出的函数调用关系来自于kernel 3.13.0,如果你的内核不是这个版本,函数名称和相关路径可能不一样,但背后的原理应该是一样的(或者有细微差别) 网卡到内存 网卡需

CORE网络数据包接收传递过程分析

能够接收实际网络流量是CORE的一个显著优点,这使得已有的系统能方便地接入虚拟网络进行模拟.CORE对网络设备的虚拟是通过LXC技术来实现的,而对网络的虚拟则是通过虚拟网卡(veth).网桥(Bridge).Quagga来实现的.本文档主要通过分析CORE中网络数据传递过程,来理解CORE网络模拟. 拓扑结构 为了方便描述,以如图1所示拓扑结构为例子,分析数据流从网卡eth0到虚拟节点n2的过程. 图1 示例拓扑 虚拟网络创建由CORE后台根据前台的拓扑结构和配置,执行相应的命令进行实现,如下:

Linux网络 - 数据包的接收过程【转】

转自:https://segmentfault.com/a/1190000008836467 本文将介绍在Linux系统中,数据包是如何一步一步从网卡传到进程手中的. 如果英文没有问题,强烈建议阅读后面参考里的两篇文章,里面介绍的更详细. 本文只讨论以太网的物理网卡,不涉及虚拟设备,并且以一个UDP包的接收过程作为示例. 本示例里列出的函数调用关系来自于kernel 3.13.0,如果你的内核不是这个版本,函数名称和相关路径可能不一样,但背后的原理应该是一样的(或者有细微差别) 网卡到内存 网卡

[转]Linux网络 - 数据包的接收过程

转, 原文: https://segmentfault.com/a/1190000008836467 ----------------------------------------------------------------------------------------------------------------- 本文将介绍在Linux系统中,数据包是如何一步一步从网卡传到进程手中的. 如果英文没有问题,强烈建议阅读后面参考里的两篇文章,里面介绍的更详细. 本文只讨论以太网的物理网

uip UDP server广播模式(client能够随意port,而且主动向client发送数据)

眼下移植uip,发现UDP server模式下,必须指定本地port以及clientport,否则仅仅能讲clientport设置为0,才干接收随意port的数据,可是无法发送数据,由于此时clientport设置为0了,我通过将原始数据包中的clientport保存下来,而且在发送的时候将clientport替换为指定的port,发送完毕之后又设置为0,这样就实现了向随意clientport发送数据. uip.c if(uip_udp_conn->lport != 0 && UDP

Socket编程】使用C++实现Server端和Client端

我是在Visual Stdio 2013上建立了两个工程,分别编译运行下面的两个main文件,然后进行测试的 服务端:Server.cpp #include #include using std::cout; using std::cin; using std::endl; #include using std::string; #pragma comment(lib,"ws2_32.lib") void main() { //创建套接字 WORD myVersionRequest;