如何在这个系统内进行通信？
我们打算设计一个具有三个“层”的系统。
- 总部，有一台服务器，
- 在区域内有大量“节点”
- 用户，配有 iPad。
HQ 与节点进行 2 路通信，节点与用户进行 2 路通信。用户从不与总部沟通，反之亦然。
权力机构规定总部的 Windows 应用程序（使用 Delphi）和用户 iPad 的本机桌面应用程序。他们对节点没有意见。
如果有令人信服的技术论点，我也许能够击败他们，从“法令”转向“更喜欢”Windows 程序（例如，使其基于浏览器）。节点没有 GUI，它们只是坐在那里扮演中间人。
这些东西通信的最佳方式是什么（SOAP/HTTP/AJAX/jQuery/home-brewed-protocol-on-top-of-TCP/其他东西？）最好端到端使用相同的协议，还是hq<-->node 和 node<-->iPad 有不同的协议吗？
这两个接口的两端可能都希望启动一个事务（如果我推出自己的协议，我可以轻松地做到这一点），那么我应该使用推/拉/长轮询还是什么？
我希望这个描述是有意义的。如果没有，请提问。谢谢。
更新：
文件大小通常低于 1MB，不可能超过 10MB 甚至 5MB。在第一个文件被确认之前，不会发送第二个文件。
文件从总部“下坡”流向节点，再到 iPad。文件永远不会“上坡”流动，但会有一些小数据包（除了 ack 之外），这些数据包是由 iPad 上的用户操作发起的。这些将发送到本地节点，然后发送到总部。我们可能正在谈论 <128 字节。
我想还会有一般控制和控制。维护交通流量低，四通八达。
We intend to design a system with three "tiers".
- HQ, with a single server
- lots of "nodes" on a regional basis
- users, with iPads.
HQ communicates 2-way with the nodes which communciate 2-way with the users. Users never communicate with HQ nor vice-versa.
The powers that be decree a Windows app from HQ (using Delphi) and a native desktop app for the users' iPads. They have no opinion on the nodes.
If there are compelling technical arguments, I might be able to beat them down from "decree" to "prefer" on the Windows program (and, for isntance, make it browser based). The nodes have no GUI, they just sit there playing middle-man.
What's the best way for these things to communicate (SOAP/HTTP/AJAX/jQuery/home-brewed-protocol-on-top-of-TCP/something-else?) Is it best to use the same protocol end to end, or different protocols for hq<-->node and node<-->iPad?
Both ends of each of those two interfaces might wish to initiate a transaction (which I can easily do if I roll my own protocol), so should I use push/pull/long-poll or what?
I hope that this description makes sense. Please ask questions if it does not. Thanks.
Update:
File size is typcially below 1MB with nothing likely to be above 10MB or even 5MB. No second file will be sent before a first file is acknowledged.
Files flow "downhill" from HQ to node to iPad. Files will never flow "uphill", but there will be some small packets of data (in addition to acks) which are initiated by user action on the iPad. These will go to the local node and then to the HQ. We are probably talking <128 bytes.
I suppose there will also be general control & maintenance traffic at a low rate, in all directions.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
对于推/拉（发布/订阅或点对点通信），可以使用跨平台消息代理。我不确定是否有适用于 Microsoft Message Queue (MSMQ) 的 (iOS) 客户端库，但我也会评估开源解决方案，例如 HornetQ，Apache ActiveMQ，Apollo、OpenMQ、Apache QPid 或 RabbitMQ。
所有这些解决方案都为分布式消息传递提供了可靠的基础，例如故障转移、集群、持久性、高性能和附加的许多客户端。在此基础设施上，可以交换任何内容类型（JSON、二进制、纯文本）的消息，并且顶部消息可以包含路由和优先级信息。它们还支持事务消息传递。
Delphi 和 Free Pascal 客户端库可用于许多企业级开源消息传递产品。 （我是其中一些的作者，支持ActiveMQ、Apollo、HornetQ、OpenMQ和RabbitMQ）
For push / pull (publish / subscribe or peer to peer communication), cross-platform message brokers could be used. I am not sure if there are (iOS) client libraries for Microsoft Message Queue (MSMQ), but I would also evaluate open source solutions like HornetQ, Apache ActiveMQ, Apollo, OpenMQ, Apache QPid or RabbitMQ.
All these solutions provide a reliable foundation for distributed messaging, like failover, clustering, persistence, with high performance and many clients attached. On this infrastructure message with any content type (JSON, binary, plain text) can be exchanged, and on top messages can contain routing and priority information. They also support transacted messaging.
There are Delphi and Free Pascal client libraries available for many enterprise quality open source messaging products. (I am am the author of some of them, supporting ActiveMQ, Apollo, HornetQ, OpenMQ and RabbitMQ)
查看 MessagePack：http://msgpack.org/
另外，这里还有更多关于 SO 的 RPC 讨论：
您可能会对 ICE 感兴趣：http://zeroc.com/index.html
他们有一个 iOS 层： http://zeroc.com/icetouch/index.html
Check out MessagePack: http://msgpack.org/
Also, here's more RPC discussion on SO:
ICE might be of interest to you: http://zeroc.com/index.html
They have an iOS layer: http://zeroc.com/icetouch/index.html
恕我直言，决定使用哪种技术的必要条件太少了。交换哪些数据、交换频率、大小？是否有请求/响应时间限制？等等。在深入了解您的需求之前，切勿开始选择技术。
IMHO there are too little requisites to decide what technology to use. What data are exchanged, how often, what size? Are there request/response time constraints? etc. etc. Never start selecting a technology before you understand your needs deeply.