不帅任你踹
我之前安装了 Windows 10 和 Mac OS 双系统，使用 Clover 引导，BIOS 界面之后直接可以进入系统选单界面。现在换成您的 OC 引导之后，启动时会在 BIOS 界面之后卡 3 分钟左右，然后就直接进 Windows 了，我开始以为是没有找到 Mac OS 分区，但是后来打开 show picker 选项之后，发现是卡 3 分钟之后才会出现系统选单的界面，默认第一项是 Windows，所以是卡 3 分钟之后进 Windows，如果在显示系统选单界面之后，选择...
## 应用场景 有些时候，我们需要在客户端之间相互调用，或者希望服务器端可以调用客户端发布的方法。如果 RPC 提供了反向调用的能力，就可以实现客户端和服务器端的双向调用了。 ## 实现原理 在 Hprose 现有的 RPC 协议基础上，通过对参数和返回值的特殊约定，将调用和返回过程反转。 ## 具体实现 首先跟推送类似，客户端首先发送一个请求给服务器，目的仅仅是让服务器可以反向传递请求，客户端请求格式如下： ``` Hm1{s2"id"s36"AFA7F4B1-A64D-46FA-886F-EF6432AD69A3"}Cu!z ``` `H` 部分是客户端传递给服务器端[共享数据](https://github.com/hprose/hprose/issues/7)，其中可以包含多项内容，但是对于反向调用来说，`id` 部分是必选项，它表示客户端唯一 id。 `C` 部分原本是表示客户端对服务器的 RPC 调用请求，这里采用了一个特殊的方法名（`!`）来表示这是一个反向调用请求。 当服务器没有对客户端进行反向调用时，该连接一直保持，直到服务器超时，或客户端超时。 如果服务器超时，服务器返回： ``` Ra{}z...
Hprose 2.0 中增加全双工和半双工的 TCP/Unix Socket 绑定实现。 但是因为对于数据长度没有校验，因此如果服务器收到随便乱发的一堆数据，会很容易因为长度问题导致崩溃。 因此，Hprose 3.0 中希望对这种情况做出改善。 首先半双工相对于全双工通讯除了实现简单一些，没有任何优势，因此可以考虑 Hprose 3.0 中不在区分全双工和半双工通讯，统一改为全双工通讯。 其次，原来全双工的通讯的头部有8个字节用来标识数据长度和请求唯一标识，这 8 个字节的意义和格式保持不变，然后在这 8 个字节之前，再加 4 个字节的校验，其值为这 8 个字节的 crc32 值。 然后通过这个校验就可以有效的排除乱发的数据，这样，即使要攻击服务器，也需要精心构造请求格式。 其次在实现上，服务器端可以增加请求长度最大值的限制，超过这个限制的请求，在读取完请求长度的 4 个字节之后，就直接关闭连接就可以了。这属于实现部分要做的事情，在通信协议中不做体现。 剩下的包体部分，可以是任意内容，这样既可以传输...
Hprose 从 2008 年开始设计开发，从最初仅支持 HTTP，到后来增加了 WebSocket、TCP、UnixSocket 支持，以及在 Hprose 2.0 中增加了服务器推送等功能。这些都是在最初通信协议的设计下完成的。并未对通信协议本身做以修改。因此，Hprose 2.0 实现可以完全兼容 Hprose 1.x 的实现。 虽然 Hprose 2.0 目前已经满足了大多数开发者的需求，但是本着可以做到更好的目的，特开此贴，希望能够汇总广大 Hprose 开发者、用户及爱好者的意见建议和新需求，如果可能，将会把它们添加到下一版的 Hprose 3.0 中去。 所以，如果你有什么新的需求和想法，请不要吝啬你的文字，你可以开一个新的 issue，把你想说的内容用最详尽的方式表达出来，包括需求描述，应用场景描述，现有协议和实现为何无法满足，具体的改进和实现的细节等等。之后，你可以将你开的 issue 发到本贴的回复中。具体做法可以参照二楼回复。 **格式不要求统一，但是请不要一句话带过，不然除了你自己，谁也不知道你想要的是什么。** 欢迎大家积极参与讨论。
Hprose 2.0 中增加了服务器推送的功能。但是该功能目前仍然有一些问题需要解决： 1. 客户端超时必须要大于服务器端超时，否则，客户端可能会收不到或丢失部分服务器端推送的数据。 2. 当客户端短时间内关闭并重启，且使用同一个客户端 id 来订阅推送主题时，客户端会收不到或丢失部分服务器端的推送数据。 3. 当服务器对客户端进行高频数据推送时，客户端如果来不及响应，客户端会丢失部分服务器端的推送数据。 4、无法推送 null，无法推送异常。 5、无法快速退订主题。 要解决这些问题，就需要对现有实现做出修改，下面是如何修改的一些想法。
Hprose 旧版本协议中，当提交的请求中只包含结束符 'z' 时，返回一个以 'F' 开头的方法名列表。 在这种方式下，无法用一个统一的编解码器来处理所有请求和返回结果，这使得让用户自己定制编解码器这个需求变得十分困难，即使强行实现，也会让编解码器在接口方面显得很不优雅。 所以，在 Hprose 3.0 中，决定使用跟远程调用一样的方式来获取方法名列表。 请求： ``` Cu~z ``` 响应： ``` Ra4{u~u#u*s5"hello"}z ``` 这里获取服务列表的方法名用一个特殊字符 `~` 表示，这样可以防止跟正常的远程调用方法名冲突。 返回的结果如同正常调用一样返回一个字符串数组的结果。跟原来相比，仅返回的开始标记不一样，后面的内容是一样的。因此不会增加冗余。 上面的返回列表里面我们看到有3个特殊字符串的方法名，它们分别是 `~`，`#`，`*`，其中 `~` 就是上面获取服务方法列表的方法名，`#` 是 hprose 2.0...
在 Hprose 1.x 和 2.0 版本中，每个调用的上下文对象都是在客户端和服务器端独立传递的，虽然这在一定程度上能够满足大多数情况的需要。但是有时我们还希望能够通过方法参数和返回结果以外的方式在客户端和服务器之间传递某些共享数据信息，实现类似于 HTTP Header 一样的功能。 下面我列出两种解决方案，请大家投票。
when I build zfs 2.1.9 from https://github.com/openzfs/zfs/releases/tag/zfs-2.1.9 ``` checking kernel source and build directories... done checking kernel source directory... /usr/src/linux-headers-6.1.20-x64v3-xanmod1 checking kernel build directory... /usr/src/linux-headers-6.1.20-x64v3-xanmod1 checking kernel source version... 6.1.20-x64v3-xanmod1...
if `/mnt/c/Users/andot/AppData/Local/Programs/Microsoft VS Code/bin` in `$PATH`, it will be spilt to: `/mnt/c/Users/andot/AppData/Local/Programs/Microsoft` `VS` `Code/bin` This pr fixed this bug.
Bluetooth can detect the devices, and when I clicked the device, it displayed "connected", but the device can't work, and a few seconds later, the device will be disconnected. My...