StackNi
(StackNi)
1
首发于小众软件：一款高三学生开发的局域网通信与控制工具
软件简介
这是一款基于 UDP 协议的局域网远程通信与控制工具。
不需要联网，不需要注册账号，只要两台设备在同一局域网内，就能互相发送消息、执行命令。
由一名高三学生独立开发，目前已稳定运行于实际教学环境中。
相关链接
核心功能
- 发送大屏消息：支持跑马灯、打字机、闪烁、公告、全屏等多种显示模式，可自定义持续时间，适配不同场景需求。
- 远程执行 CMD 命令：支持系统权限和用户权限两种执行方式，适配教学机房和办公环境。
- 智能提示词系统：可为常用 IP 设置提示词（如"教室主机"“办公室电脑”），发送时直接选择即可，无需手动输 IP。
- 精细化的消息状态反馈：发送后实时显示对方是否确认收到，支持超时提示和错误状态分类展示。
- 深色主题 UI：简洁清爽，适合长时间在教室或办公室使用。
- 支持跨平台：发送端已推出 Windows 桌面版（带交互界面）和 Android 版；接收端目前仅限 Windows。
下载地址
Windows 发送端+接收端（3.2.0）：
Android 发送端（3.2.0）：
使用说明
- 发送端与接收端需处于同一局域网。
- 接收端目前仅支持 Windows 系统。
- 建议目标设备使用固定 IP，或通过提示词系统提前绑定，便于日常操作。
免责声明
本工具仅限在互相知晓并同意的局域网环境下使用，请勿用于未经授权的设备或恶作剧行为。
作者不对因滥用或误用本工具所造成的任何后果承担责任。请合理使用，共同维护良好的网络环境。
适用场景
- 教室多媒体消息推送
- 机房统一管理
- 办公室内部快速通信
- 局域网内轻量级控制
软件截图
关于作者
现为高三学生，课余时间独立开发。
如果您觉得这个工具在课堂上或办公室里对您有帮助，欢迎在 GitHub 上给个 Star。
如果使用过程中遇到任何问题，或者不确定怎么配置，欢迎加群交流：
QQ 群：1053383479
目前群里人不多，但我一直在。提供使用建议、反馈问题、催更需求，都欢迎。
来了就别走咯～
3 个赞
初高中阶段不影响学业的情况下爱鼓捣这些是好事，不过别把 GitHub 当云端 WPS 用啊，你仓库 commit 记录的可读性非常差，肉眼可见全是通过 GitHub 网页版上传文件和管理文件的，只看 commit 记录完全看不出来改了什么（甚至仅有的几条可理解的 commit 描述似乎也是 GitHub 网页在提交时自动用 AI 总结的），建议有空的话学习一下 git 的基本用法。
再贴一个青蛙的仓库 commit 记录作为正面案例（虽然下面有几条青蛙也偷懒用网页版 
）：
另外，编程语言的选择非常小众，Pascal 这种我都只能在 NOIP 中见到，开发者是竞赛生还是纯爱好？如果是纯爱好的话，建议换一门语言吧，Pascal 在设计理念上已经落后现代工程实践太多了。
3 个赞
StackNi
(StackNi)
4
谢谢你写了这么长的评价，我空下来一定会好好研究的。至于编程工具，我电脑配置太低了，现代工具一个都跑不了
。pascal是最后的选择了……毕竟Indy库稳定嘛，做这个工具很快，而且用户根本不关心你用的什么工具。如果我用pascal做AI，那是我方向完全错了。但是我个人认为这个场景下，使用拥有成熟的网络组件的工具来做，确实是最佳的选择了，就算语言现在已经不流行。工具是手段，能解决问题才是目的。这个工具已经在教室环境里稳定跑了，说明我的选择没拖后腿，这就足够了。
2 个赞
wankkoree
(Wankko Ree)
7
我不太熟悉 UDP 通信，帮不上这方面的忙。
我平时还没碰到过适合用 UDP 这种不可靠传输的场景，因为绝大多数业务环境都需要确认数据是不是发送到位，但是 UDP 要实现的话相当于自己再封装一层可靠会话，不如直接用 TCP 来得方便。
我印象里 UDP 通常是用在发送方只管发送不管送达的情况，比如各种推流（教室投屏的画面流、视频会议的视频流）、数据上报（工控机器给上位机定时上报数据）、低延迟应用（在线游戏）
不确定你具体碰到了哪方面的问题，如果是连接可靠性方面的问题，我的建议是换 TCP，因为在需要数据确认送达的场景下，给 UDP 实现各种可靠连接的特性远不如换成 TCP 来的简单。
StackNi
(StackNi)
8
我这个确实是用来局域网发公告的，考虑到UDP无延迟，就用了UDP，ACK都是我自己在UDP上搭建的。还好啦其实。
1 个赞
StackNi
(StackNi)
11
www垂直领域的需求果然不适合大众的口味（我老师用着挺好的呀
）
lanxiuyun
(Lanxiuyun)
12
额。。主要是在外面，大家都有互联网，局域网环境通信就没啥用了。。
用微信不香么。。
建议的初心是好的，但有些严厉了，我个人想补充几点。
小孩哥用Pascal，大概率是手搓的，不是AI的。事实上，不知道为什么，在现在这个时代，我开头一看见高三党这三个字就感觉这工具八成是AI写的。我觉得首先要肯定手搓编程。
其次，用Pascal的原因我估计跟什么上古编程竞赛有关。我记得20年前我读高中的时候，高中级别的编程课程和竞赛用的是 Pascal。可能当地的竞赛语言没变？或者是那个时候因为兼顾竞赛招聘的计算机老师现在因为编制原因换不了了，（20年前老师25，现在45等退休也不想学新的语言了）？
第三，不会用github，也情有可原。用我自己举个例子，我不是大佬，但也会一点手搓编程，初中的时候用delphi，现在用arrdio。都是小众的win原生语言。git和svn都是我年纪大了才出现的东西，而且我本身工作与编程完全不相关。于是我也几乎完全不懂git相关命令，除了玩ComfyUI时候要git clone插件而已。以至于我自己写的小软件也往往只放在远古网盘上，而不是github。
事实上，只要愿意公开源代码，总的来说就是正面的。尤其对于一个高三小孩哥。君不见多少创作者打着“开源”的擦边球，在github上上传一个编译完的exe，其他就写个readme，把github当免费的下载站用。美其名曰只要在github上下载就算程序开源，源代码涉及个人机密实现不开源。（流汗黄豆，这种软件我默认加料）
总的来看，一个小孩哥能纯手搓写个这个已经算壮举了。虽然我没去看代码怎么实现的，不过一个完善的带回显的CMD，实现方式有几种，能写好并不容易。
相比起前段时间，看到有人分享一个自己用python打包的软件，一个数据库功能的软件，好家伙下载回来空表就体积上G（什么硬盘销售商合作伙伴）。说自己单文件清爽，结果一万个运行时文件解压缩在appdata里。我想说，同样是非编程职业相关的人做的独立开发，这个真的是清流。
3 个赞
如果不是非要用pascal，可以学学C++或者其他语言，然后直接用kcp这种通信库。所有“可靠”“优化”过的UDP网络传输，本质上都是自己写了一个变种版TCP。只不过根据自己的需要进行了变种。
比如KCP被人诟病的就是无脑重发可能在区域性网络状况总体不佳的情况下，自己疯狂发包反而进一步挤占了有限的网络资源。
不过我大概能猜测，UDP的非阻塞式，也不用选链接session，手搓的时候在逻辑上比较简单。TCP在某些语言下的实现，逻辑上有些不太直观。可能你喜欢用UDP而不是TCP，可能就是你当下在用的TCP实现你觉得思路上有点绕弯子？
这个也是可以通过找一个你比较舒服的可靠UDP实现的包来改善的。（当然这也要牵扯到转C语言等更主流的语言才有包用）
现代C/C++/C#语言对新手入门可能有点困难，特性太复杂了(autoautoauto梗)，写个hello world可能连设置cmake那一关都过不了，就挺头疼。如果从难度的角度上讲，我建议你看一下arrdio语言。国内一个大佬开发，整体比较简洁，语法上c like基本上有点语言基础就能看懂（所有arrdio的独特语法糖你基本都可以当不存在也能照样写程序），学了后续你有时间再进一步转C/C++也顺。win原生语言，编译出来的exe体积小，也大多不需要什么运行库支持。（堪称现代delphi）
2 个赞
StackNi
(StackNi)
15
老师抱怨学生缺交作业还得一个个叫，我想到教室大屏可以用来最大化展示内容，于是我造了这个工具，我老师觉得好用，用它发通知还不用跑楼梯，微信做得到？局域网只是手段，不是衡量工具好坏的唯一标准。微信和它各管各的场景，没必要硬比。真有改进建议我欢迎，光丢一句“还得练”算什么话？
1 个赞
PigeonCast
(https://pigeoncast.com)
17
1 个赞
StackNi
(StackNi)
20
非常感谢你花时间写这么长的回复，每一条我都认真看了，也很感谢你帮我解释。
关于Pascal，其实跟竞赛没什么关系。我自己搞数据分析竞赛的时候用的都是Python，也拿过奖。现在这个项目用Pascal和C#，纯粹是因为我电脑烂，FMX和WPF能跑得动，而且FMX还能跨平台，在这个场景下能最快解决问题。我一开始也是想用Qt做这个的，如果我的电脑能跑Qt，我当然会欣然选择C++，可事实上我尝试了各种办法也没能用成Qt。考虑到我时间本来就少，现有的工具能帮我解决问题就行了。
至于AI写代码——我又不傻，我当然用了AI辅助，但亲手改的确实更多。Delphi发送端业务逻辑就有3000多行，C#接收端的代码量远不止这个数。AI给了我UDP的使用模板，教会我怎么绑端口，用IP，但整个通信逻辑、界面交互、多端协议对齐，都是我一行一行调出来的。Pascal这边因为我在用FMX的时候遇到了各种bug，气得我直接把它的源码捞出来改了——窗口恢复状态一塌糊涂，我去消息泵里改WM_和SC_分支里的逻辑；TControl点击事件定义有漏洞，我加了个标志位修好，总共改了少说几十处，还提交了PR给官方。我现在对Windows底层消息机制非常敏感，就是这个语言教给我的。说实话，如果要我现在去设计个新的跨平台框架我都能接受，只是当下没这么多时间，就先把别人的框架研究透了。
GitHub上显示Pascal占比高，是因为我把修改过的FMX框架源码也扔进了仓库——那玩意儿本身就有几万行，业务逻辑其实是C#比Pascal多。
工具是解决问题的，能最快解决问题的就是好工具。语言之争我不参与，没意义。何况Object Pascal和C#都是Anders Hejlsberg设计的，语法工整，事件驱动完备，以后学其他语言也轻松。这个项目我大部分时间花在UDP可靠性、消息协议设计、用户体验上，而不是纠结语言。
最后，谢谢你说这算“壮举”。它确实已经在我教室里跑起来了，大众不需要它没关系，我老师依赖它，就够了。
KCP - A Fast and Reliable ARQ Protocol