C#吧，Winform ，拖拽个界面。使用 HTTP 协议与 Java 通信交换数据，例如 Flurl ；
然后 Java 端内置一个 Jetty 作为 web 服务；

缺点： 仅适用于 Windows ，无法跨平台；界面稍微不注意会很丑
优点： 快，Java 端逻辑可以完全复用。

换个梯子的节点就好了,可能是某些节点的问题.

@pkoukk 或许你根本不理解什么是 "计算机语言" 手动狗头
1. 你认为的生态如何重要了?

2. 那 Go 语言的设计逻辑与 Java 差别在哪里了?

3. 各有适应场景又如何解释?

请赐教

在这里我一直感谢我之前的老板,不断的强调:"语言只是工具,核心是动态模型". 如果理解这句话,从 Python 转 Go, 一周就可以上手了.

语言所具备的几个基本点:
1. 变量
2. 类型
3. 条件分支 /循环
4. 函数
这些内容,只要会了一门语言,学一门新语言应该说是 1,2 天熟悉一下就可以了. 即便一下子记不住,后续回过头来查一下即可.
可能需要花点时间的也就是 协程 ,但是如果你多线程和异步的概念很扎实的话,协程也很简单. 而多线程,异步就是所谓的 "动态模型" 而这部分内容是与计算机语言无关的.

1. 办一个禅修学院,真正教授正确修行方法的地方.
2. 去西藏某个寺院出家

String contenxt = File.read("path");

首先,代码运行是在 CPU 中执行;

其次,CPU 再向 IO 设备,例如内存,硬盘,或者网络发出读写指令;

最后,CPU 等待 IO 设备反馈;

此时,问题就来了,CPU 以纳秒为单位, 无论是内存,硬盘,还是网络,尤其是网络 以毫秒为单位,相差了多少倍,请自行换算.

就意味着,如果是同步 IO 模型,那在 CPU 发出读写指令后,会令当前线程

阻塞

阻塞

阻塞

等收到设备数据后,当前线程,继续往下执行.

针对以上过程,所谓的 "性能" 也好 "吞吐量" 也好,绝大多数浪费在了 CPU 等待 IO 设备反馈的时间上了. 那如何解决这个问题呢?
请自行阅读 https://segmentfault.com/a/1190000039898780 5 种 IO 模型.

所以如果想提高 "性能" 两方面入手:

1. 框架本身基于更高效的 IO 模型
2. 业务层代码,也使用更高效的 IO 模型库:

比如将 同步 IO 代码

String contenxt = File.read("path");
更换为 异步 IO 代码
String contenxt = await File.read("path");

async / await 都是语法糖,语法糖,语法糖,只是语言层面为了开发人员简化书写提供的便捷写法. 而底层 IO 机制无外乎前文中的 5 种 IO 模型

.idea,.gradle 目录已经移除了.

@danc 我现在仅仅算是用基恩士上位链路协议跑通阶段. 后面肯定扩展其他协议. 但这方面网上的协议资料不好找,你可以分享一下关于协议方面的资料吗

@wengang285 根据实际场景选择吧,例如 数据量相对较大,且 buffer 小的时候,如果不尽快从 buffer 中取出数据, 引发 流量控制机制,反而导致整体传输变慢.

多谢,目前是用 Java 基于 Netty 做. 想先做好 稳定性 只采集,也够支持目前数字化车间的应用场景了. 且最低可以稳定在 5ms~10ms 的采集周期也足以应付绝大多数数据采集续期. 稳定性,协议多样性以后,再想办法扣速度. 支持可靠的写入特性.(与 plc 做写入交互,确保确实写入了.)

@wengang285
但也可以是 长度（ 4 字节）+buffer，缓冲区可读,那么查看先读长度，然后根据长度往后取 buffer,有多少取多少,因为没有取够, 那么下一次再次通知的时候,与上一次的已经取出来的拼接,直到取够 "长度" 为一次完整帧.

@deavorwei
TCP 保证了 有序性,完整性. 是指:
发送端 发送了 #1 2 3 4 5$ #a b c d e$ . 接收端最终收到的也是 #1 2 3 4 5$ #a b c d e$ 有序,且完整.
但是

接收过程

接收过程

接收过程

(重要的点) 会是这样的
情况 1: #1 2 3 4 5$ #a b c d e$
情况 2: #1 2 3 和 4 5$ #a b c d e$
顺序没乱,且数据没丢.

@darknoll 54 楼 并不是虚构的协议. 可以参考
1. Modbus ASCII 在 ASCII 传输模式下，消息帧以英文冒号”:”（ 3A ）开始，以回车（ 0D ）和换行（ 0A ）结束.
2. 基恩士 PLC 中的 上位链路协议: [功能码] 开始,回车（ 0D ）结束.

@darknoll 不是说所有协议都是这种模式"magic number+数据长度". 自己研究去吧

“TCP 的粘包问题” 确实不严谨.这点我也承认.

"基于 TCP 传输数据,必然存在应用层数据的 粘包 /拆包问题".

如果写过 TCP 通信(Socket 编程)的懂得自然懂,不懂得说多了也没用, 可以参考 Netty 中的
LineBasedFrameDecoder : 基于回车换行符的解码器
DelimiterBasedFrameDecoder: 分隔符解码器，可以指定消息结束的分隔符
FixedLengthFrameDecoder: 固定长度解码器，它能够按照指定的长度对消息进行自动解码
LengthFieldBasedFrameDecoder :一般协议头中带有长度字段，通过使用 LengthFieldBasedFrameDecoder 传入特定的参数，来解决拆包粘包

@ckdxc 你说的这是一种,我没记错,应该叫做 "定长协议" ,就是一个数据段固定长度,比如 512 个字节.每次固定取这么长度的就可以.
但是还有"可变长度"的协议,就需要在数据段中某个固定位置上指示 本次数据自身的长度,例如: #3abc,#5abcde.
表示 #开头,随后的数字表示后续数据的长度,比如 3,5,分别表示在此之后还有若干个数据才算一段完整的数据集.

还有另外一种,固定以回车换行符为分隔符的,无论多长,只要有回车换行符就切断

@leonme
@raptor
@allenby
@dcoder
@hahasong
@lasfresas
"Talk is cheap ,Show me the code"
请贴出你们针对 54 楼问题的代码

假设有一个数据源,源源不断的产生数据,需要通过 TCP 传输,同时,这些数据是一段一段的;
假设以#开头,以$结束. 比如 #abc123$ 为一段完整数据.
应用层代码接收到数据时,就会出现如下三种情况:
1. 刚好收到完整的数据: #abc123$
2. 分为了 2 次收到完整数据: 第一次: #abc ; 第二次: 123$
3. 1 次收到数据,多于一段完整数据: #abc123$#ab

请问你的代码如何处理以上三种情况?
onData("#abc");
onData("123$");
onData("#edf456$#hj");
onData("k789$");
最后希望得到的是

#abc123$
#edf456$
#hjk789$


private String cache="";

public void onData(String data){
// 请把这里补充完整,就理解了.
}

主要是为了 扩展性 . 比如你设计一个框架可以这样来做

// 可以是接口,也可以是函数,或者是其他
[函数|接口] hook=null;

// 注册钩子函数
function addHook([函数|接口] hook){
this.hook=hook;
}

// 此函数就可以由于钩子函数的存在,在不修改代码的基础上通过传入不同的钩子实现不同的逻辑
function something(Object args){
// 比如首先参数验证,然后做一些处理
if(this.hook!=null){
args = this.hook(args); // 调用钩子函数
}
// 后续的操作
// 如果没有注册钩子函数,则系统就是默认行为.
// 如果之前添加了自定义的钩子函数,可以对系统默认行为作出自定义
}