java - 无需中介即可从网络服务器打印到热敏打印机

Question

我一直在研究这个问题近一个月了。似乎我被推向了各个不同的方向。我希望有人能帮我解答。

给出我正在寻找的简要模型:

我有一个网络服务器，里面有我需要通过互联网到达热敏打印机进行打印的信息。我不希望计算机成为中介。我可以进行必要的编程来实现这一点。我的问题是通过找到我能够编程的设备来解决的。我遇到的第一个问题是找到一台带有内置网络服务器的热敏收据打印机，我可以通过编程来轮询我的服务器以获取要打印的信息。目前没有可用于此目的的打印机。我与 Zebra、Epson、Brother 等进行过交谈。如果两个设备都在同一网络上，例如手机打印机到手机连接到的同一网络上的打印机，大多数都有打印解决方案，并且大多数都有 SDK 到做吧。我需要打印机能够轮询我的网络服务器。所以我去寻找替代品。也许我可以将无线 USB 迷你网络服务器连接到打印机以达到我的最终目标。我认为这将是一项简单的任务，但事实并非如此。我对 stackoverflow.com 上的用户的问题是有人遇到过类似的问题并知道解决方案吗？我再次与不同的制造商进行了交谈，但他们都无法提供帮助。我想他们中的大多数人甚至无法理解我在说什么。我希望在这里编程的人理解我的问题。

以下是我正在尝试做的本地回旋解决方案。

http://proto-pic.co.uk/internet-connected-thermal-printer-kit/

同样，上面的这个解决方案要求我从头开始构建它。 berg 云是另一种选择，但它们不允许我控制我的 Web 服务器，一切都通过它们运行。请随时提出问题，因为我不希望快速回答​​这个问题。希望有遇到过类似问题的程序员。

还要引用我为这个问题选择的标签，我想也许我可以将一个设备(Web 服务器微 Controller 设置)连接到热敏打印机，该打印机可能有一个运行网络服务器的 JVM，然后我可以通过 USB 与打印机进行通信。我知道对于微 Controller 来说，Java 比 C 糟糕得多，但这是我所知道的。很想听听任何替代解决方案。

Answer 1

我强烈建议您此时重新考虑 Zebra websocket 解决方案。

最好的解决方案仍然可能是迷你 Web 服务器解决方案。

我使用 Zebra websocket 解决方案的经验:
背景:

我最初尝试创建一个 node.js 解决方案(我在几个地方读到任何服务器都可行)。
但是，即使在获得 Zebra 签名的证书之后，在几次连接尝试失败后 - 并且打印机/服务器通过成功的握手过程 - 它仍然失败并出现一个神秘的错误，当调查与试图验证特定 Tomcat 的打印机有关时正在使用版本/服务器!!!？？？

我确实收到了 Zebra 开发人员的回复，他正在开发 .Net 解决方案，但也无法使其正常工作，并且正在等待 Zebra“工程师”提供更多信息，然后他们才能完成解决方案。他们说他们会在收到信息后将其发送并希望在一周内收到(超过一周 - 还没有运气)。

所以 - 我决定组装一个 Tomcat 服务器 - Zebra 唯一可以工作的例子......我让示例 servlet 运行但开始遇到新的证书问题(因为我改变了服务器/域等)
这让我想到了整个笨拙的过程 - 并认识到 1 个交易破坏者 - 非常严格的 ssl 身份验证和签名过程风险太大。

例如。假设您有 100 多个客户依赖此解决方案。
如果您的证书有问题(例如域名更改、服务器设置更改或证书失效/到期)，那么所有 100 多个客户都没有打印机。
但是您不能自己修复它 - 修复/生成新证书等。重新签名过程很慢并且依赖于外部资源! (顺便说一句，这是一个手动 Zebra 流程 - 您通过电子邮件发送，然后在 Zebra 员工回复签名证书之前等待相当长的时间)。

这意味着所有 100 多个客户在相当长的时间内都没有打印机服务，但您别无选择，只能让 Zebra 签署您的证书。对我来说，这是一个 Not Acceptable 风险 - (websocket 解决方案不应该依赖于 Zebra 签名的证书 - 毕竟你正在安装你的(或你的客户端)打印机，然后配置打印机以指定一个确切的域名/地址连接到)。

使用您的迷你服务器解决方案 - 如果客户有问题 - 它只会影响该单个客户，并且您不依赖外部公司签署证书来解决问题。

以下是已识别的问题及其相关风险。

问题 1) 实现得很差 - 我不能(他们也不能)让它连接到一个标准服务器而不是一个非常特定的 Tomcat 设置!!!
风险水平:低 - 即它是初始成本和时间负担 - 但一旦工作，这个问题导致进一步问题的持续风险是最小的。
风险:
a) 将开发限制在非常特定的服务器和技术上。
b) 初始开发/测试的时间和成本增加。

问题 2) 文档不完善 - 我已经发现(并且 Zebra 已经验证)文档中的几个错误 - 文档还散布着重要信息，这些信息被扔到一个难以找到的 readme.txt 文件中，与文档的其余部分分开。
风险水平:低 - 即它是初始成本和时间负担 - 但一旦工作，这个问题导致进一步问题的持续风险是最小的。
风险:
a) 减缓初始发展。
b) 初始设置/开发的时间和成本增加。

问题 3) 打印机安全/ssl 身份验证计划和实现不当。它涉及多个步骤 - 限制性极强，并且涉及缓慢的斑马签名过程，这会产生持续的风险。
风险级别:高 - 即这就是我们无法使用此解决方案的原因。
风险:
a) 将开发限制在非常特定的服务器和技术上。
b) 减缓初始发展。
c) 初始设置/开发的时间和成本增加。
d) 对项目造成持续的高风险，如下所示:
---> 想法是公司将依赖此打印机连接解决方​​案 - 因此任何潜在的停机时间都会导致重大业务中断。
---> 以下任何一种情况都意味着所有依赖此 websocket 解决方案的客户将在几天内没有打印机服务，同时组织新的 Zebra 签名证书:
---> 1) 证书过期，2) 证书失效，3) 服务器被移动，4) 域详细信息更改，5) Tomcat 服务器设置被修改(由于打印机验证某些 Tomcat/服务器设置的方式)
---> 此外，以上 5 种情况目前仅根据我的测试已知 - 可能还有其他可能的限制，这可能意味着我还没有遇到过的证书失败。

概括:
IMO 问题 3 带来了 Not Acceptable 风险，在我重新考虑 Zebra websockets 之前，需要发生以下两件事。
1) 他们需要关于 websockets 如何连接到服务器的适当文档，因为它是隐藏的，甚至 Zebra 员工目前都在黑暗中。
2) 他们需要删除一些身份验证限制 - 这样您就可以解决任何问题，而无需耗时的 Zebra 交互。