JPDA 架构研究3 - JDWP层的数据包

简介:

引入:

现在我们把目光转到JDWP层(它的全称是Java Debug Wire Protocol。从"Wire"这词就可以看出,它主要是起到"连线”的作用)。首先我们从JDWP层的数据包讲起。源码在JDK中很容易找到,它定义$JAVA_HOME/include/jdwpTransport.h 头文件中。 


分析:

Part 1: 握手过程 (handshake )

握手包发生在Debugger(JDI端)和Target VM(JVMTI端)的传输层连接建立,并且在发送任何实际数据报之前完成的。它过程如下:

a. Debugger会发送14个字节的握手请求到Target VM,这个包的内容是14字节的ASCII字符串 “JDWP-Handshake”

b. Target VM会返回14个字节的握手响应到Debugger,其内容也是14字节的ASCII字符串,和刚才一样,“JDWP-Handshake"

这样的主要作用是为了确保 Debugger和Target VM之间通信正常。


Part2:发送具体调试请求和获得响应阶段:命令包(Command Packet)和响应包(Reply Packet)

从许多文档中, 我概括了JDWP层包的一些特点:

(1)包是无状态的

(2)命令包可以通过Debugger或者Target VM来发送。

对于从Debugger发送的命令包来说,它主要可以发送请求消息或者控制程序执行。

对于从Target VM发送的命令包来说,它可通知Debugger一些Target VM中的事件比如断点或者异常。

(3)响应包

响应包用于对于某命令包的响应,它总用于返回命令的成功或失败,并且可以携带命令包中包含的数据。

对于从Debugger发送的命令包,一般总会有响应包。

对于从Target VM发送的命令包,无需要响应包。 

(4)JDWP平台对于数据包的发送是异步的,各个命令/响应包之间无顺序概念。命令包和对应的响应包通过ID来配对识别。


命令包的定义如下:

1
2
3
4
5
6
7
8
9
10
11
typedef  struct  {
     jint len;                   //命令包的长度:4字节,它是整个包的长度
     jint id;                    //命令包的ID: 4字节,用于表示命令包和对应响应包的配对,正因为此机制才可以让包是异步传输的。
     jbyte flags;            //命令包的标志位:1字节,用于定义该命令如何进队列/处理或者被打标记
     jbyte cmdSet;       //命令包的命令集:1字节,用于分组该命令 
                                 //(0-63:表示Debugger往Target VM发送的命令)
                                 // (64-127: 表示Target VM往Debugger发送的命令)
                                 //(128-256: Vendor自定义命令)
     jbyte cmd;           //命令包中的命令:1字节
     jbyte *data;          //命令包中携带的数据
} jdwpCmdPacket;

响应包的定义如下:

1
2
3
4
5
6
7
typedef  struct  {
     jint len;                   //响应包的长度: 4字节
     jint id;                     //响应包的ID: 4字节,用于表示命令包和对应响应包的配对,正因为此机制才可以让包是异步传输的。
     jbyte flags;             //响应包的标志位:1字节,用于定义该命令如何进队列/处理或者被打标记
     jshort errorCode;   //响应包中的错误码:2字节,其中0表示成功,非0表示某种错误码,一般错误码会映射到JVMTI的返回码。
     jbyte *data;            //响应包中携带的数据
} jdwpReplyPacket;


补充说明:

(1)如果接收端接受到的命令包,其中携带的命令集或者命令是规范中未定义的,那么响应包的errorCode会被定义为NOT_IMPLEMENTED.

(2)ErrorCode定义如下:

1
2
3
4
5
6
7
8
9
10
typedef  enum  {
     JDWPTRANSPORT_ERROR_NONE = 0,
     JDWPTRANSPORT_ERROR_ILLEGAL_ARGUMENT = 103,
     JDWPTRANSPORT_ERROR_OUT_OF_MEMORY = 110,
     JDWPTRANSPORT_ERROR_INTERNAL = 113,
     JDWPTRANSPORT_ERROR_ILLEGAL_STATE = 201,
     JDWPTRANSPORT_ERROR_IO_ERROR = 202,
     JDWPTRANSPORT_ERROR_TIMEOUT = 203,
     JDWPTRANSPORT_ERROR_MSG_NOT_AVAILABLE = 204
} jdwpTransportError;





本文转自 charles_wang888 51CTO博客,原文链接:http://blog.51cto.com/supercharles888/1587595,如需转载请自行联系原作者
目录
相关文章
|
设计模式 架构师 Java
阿里P8架构师都要学习研究的java加强版23种设计模式神级PDF文档
说在前面的话 Java作为老牌纯正的编程语言,在规范性上有着天然优势。因此本版的设计模式讲解全部用Java语言来描述,并针对Java语言的特性对讲解内容做了相当大的改动。 不知道大家是否听过编程界的一段话:掌握设计模式相当于华山派的"气宗",是程序员的内功修为,虽然在同样的学习时间下,类似Python这种"剑宗"的开发模式见效更快,但是长远来看,"气宗"才是走向软件架构师以上级别的必由之路。 所以,掌握气宗就掌握了编程命脉,然而学习设计模式有四大境界: 接下来给大家分享的就是java溢彩加强版大话设计模式包含的内容知识点。 总目录 主要内容 本文是百万销量的经典畅销书《
253 0
|
2月前
|
机器学习/深度学习 安全 算法
十大主流联邦学习框架:技术特性、架构分析与对比研究
联邦学习(FL)是保障数据隐私的分布式模型训练关键技术。业界开发了多种开源和商业框架,如TensorFlow Federated、PySyft、NVFlare、FATE、Flower等,支持模型训练、数据安全、通信协议等功能。这些框架在灵活性、易用性、安全性和扩展性方面各有特色,适用于不同应用场景。选择合适的框架需综合考虑开源与商业、数据分区支持、安全性、易用性和技术生态集成等因素。联邦学习已在医疗、金融等领域广泛应用,选择适配具体需求的框架对实现最优模型性能至关重要。
534 79
十大主流联邦学习框架:技术特性、架构分析与对比研究
|
3月前
|
存储 JavaScript 开发工具
基于HarmonyOS 5.0(NEXT)与SpringCloud架构的跨平台应用开发与服务集成研究【实战】
本次的.HarmonyOS Next ,ArkTS语言,HarmonyOS的元服务和DevEco Studio 开发工具,为开发者提供了构建现代化、轻量化、高性能应用的便捷方式。这些技术和工具将帮助开发者更好地适应未来的智能设备和服务提供方式。
94 8
基于HarmonyOS 5.0(NEXT)与SpringCloud架构的跨平台应用开发与服务集成研究【实战】
|
3月前
|
机器学习/深度学习 算法 数据可视化
基于深度混合架构的智能量化交易系统研究: 融合SSDA与LSTM自编码器的特征提取与决策优化方法
本文探讨了在量化交易中结合时序特征和静态特征的混合建模方法。通过整合堆叠稀疏降噪自编码器(SSDA)和基于LSTM的自编码器(LSTM-AE),构建了一个能够全面捕捉市场动态特性的交易系统。SSDA通过降噪技术提取股票数据的鲁棒表示,LSTM-AE则专注于捕捉市场的时序依赖关系。系统采用A2C算法进行强化学习,通过多维度的奖励计算机制,实现了在可接受的风险水平下最大化收益的目标。实验结果显示,该系统在不同波动特征的股票上表现出差异化的适应能力,特别是在存在明确市场趋势的情况下,决策准确性较高。
103 5
基于深度混合架构的智能量化交易系统研究: 融合SSDA与LSTM自编码器的特征提取与决策优化方法
|
5月前
|
设计模式 前端开发 JavaScript
深入探索研究MVVM架构设计
【10月更文挑战第7天】
90 0
|
10月前
|
缓存 负载均衡 Java
基于微服务架构的后端性能优化研究
基于微服务架构的后端性能优化研究
99 0
|
存储 监控 关系型数据库
ELK架构的应用与研究
ELK架构的应用与研究
174 0
|
3月前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
4月前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
95 3
|
4月前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####

热门文章

最新文章