问题标签 [protocols]

对于那些第一次听到它的人来说，它代表数字音频访问协议。这就是 iTunes 用来流式传输音乐的方式。

该协议使用 HTTP 来传递播放列表信息、流式音频等。

我查看了规格，但有很多不清楚的地方。有没有人有这个协议的更好文档的链接？

我正在为一个项目编写一个 Cocoa API，该 API 需要一个委托。我提出的协议将所有方法声明为可选，但我为什么要这样做，而不是仅在头文件中记录委托方法并将普通 id 作为参数？

我知道 Flickr 提供了 XML-RPC 和 REST 方式来使用它。

每种语言都有标准的 XML-RPC 库（例如，Python 有一个内置的xmlrpclib）。

标准 XML-RPC 库负责序列化/反序列化以及发送/接收响应。

在我看来，对相同 API 使用 REST 样式的网站最终会用每种语言编写自己的库。示例：雅虎！搜索 SDK。

对我来说，XML-RPC 方式似乎更好，但所有证据都相反。为什么？

所以：

1. 为什么大多数 Web 服务都是 REST 风格，而不是 XML-RPC？
2. XML-RPC 是否存在不明显的缺点？

我仍在尝试了解电子邮件协议。似乎 IMAP 比 POP3 更强大。那么，为什么 POP3 协议能够幸存下来呢？GMail 等流行的电子邮件服务仍然支持它。

我目前正在开发一个客户端-服务器应用程序，我想使用 XML 作为协议。现在，我不太确定声明 XML 名称空间和创建 XML 模式。

不用说服务器和客户端发送不同的东西，即客户端发送请求，服务器响应它们，因此使用不同的标签等等。双方的共同点是发送的 XML 数据是流式的，并且文档的根称为<stream>，但是 - 正如我所说 - 中的标签是不同的（每个分别代表请求或响应）。

现在，这是两种不同的 XM 语言吗？我应该为它们中的每一个声明一个命名空间（因此也声明一个 XSD）吗？还是我应该使用一个并添加一个属性“发送者”来定义端（服务器|客户端）？在后一种情况下：那么我如何区分属性值？也就是说，如何在 XSD 中声明哪个标签可以用于什么“发件人”值？

我在写一个小型的浏览器游戏，由于我不是一个好的设计师，我想先从技术部分开始，然后再添加用户界面，所以我想让第一个版本包含机器人支持，这样每个人都可以写他们自己的机器人并让它玩游戏。这样，我就不必关心为用户界面制作图形，并且可以专注于游戏的核心，同时拥有稳定的测试数据流和许多测试人员。

但是，我无法在服务器（C++）和客户端（任何语言，但第一个参考实现将使用 C++ 和 Python）之间交换数据的各种方式之间做出决定。
对于传输，我考虑提供 HTTP 和 TCP（一些简单的自制协议），因为大多数语言都有这些协议的初学者友好实现。

为了对数据进行编码，我考虑了一些由我任意定义的东西（像 CSV 之类的原始东西）、JSON 和 XML，但我想要一些关于 C++ 易用性、各种语言的简单实现和人类可理解性的评论。

我该怎么办？

我想用这段代码用 Xmodem 发送档案：http ://www.java2s.com/Code/Java/Network-Protocol/JModemsimplecommunicationsprogram.htm

在这种情况下，我想在两台计算机之间建立拨号连接并发送二进制文件。但是这段代码不允许我在设置端口之后和传输文件之前设置要拨打的电话号码。有没有办法与另一个拨打电话号码的应用程序共享端口？

当发送者需要通过以太网以可靠的方式将相对大量的数据（例如每秒几兆字节）多播到同一子网上的适度数量的接收者（例如少于十二个）时，最有效的协议是什么？可靠是指如果一个数据包丢失，协议会确保它被重新发送，这样任何接收器都不会丢失数据。高效这个词很难定义，但是假设我们想要最大化吞吐量并最小化网络带宽，同时两端的 CPU 使用率适中。这仍然不是一个明确的定义，但这是我能想到的最好的定义。面向流或面向消息的协议都是可以接受的。

我很欣赏现实世界的例子，我很乐意接受主观答案，即你最喜欢的多播协议是什么，如果你能解释它的优缺点的话。

我正在维护一个与现实世界交互的遗留嵌入式设备。一般来说，该设备从传感器收集数据，使用其内部算法对数据进行处理，并在数据达到某种“坏”状态时显示警告。

出于调试目的，我们希望该设备能够定期向我们发送它接收到的许多数据，以及处理后的数据。

我们得出的结论是，大多数数据可以用表格形式描述，类似于

我们显然需要支持不止一种表格形式。

所以基本上我们需要一个协议，能够接受一组表描述，然后根据它的描述传递表数据。

发送数据的示例伪代码是：

用于接收数据的示例伪代码是：

定义表格既可以在设备上也可以在与其通信的客户端计算机上离线完成，也可以在线完成。我们可以添加一个简单的握手协议来在设备启动时就表格的格式达成一致。

由于这是一个遗留设备，它只支持 RS232 通信，并且由于它的 CPU 非常慢（相当于 486），我们无法使用任何类似 XML 的数据传输方法。这些太昂贵了（无论是计算时间还是带宽）。由于带宽考虑，发送原始 SQL 命令也被考虑并拒绝。

[编辑]

为了澄清，也减少了每次发送表头的开销，我试图避免每次发送数据时发送表头。所以每次我发送一个表格行时，我只需要发送表格 ID。

我还想指出，我希望传递的大部分数据都是数字的，因此基于文本的协议太浪费了。

最后我看到了谷歌的协议缓冲区，它足够接近但它不支持 C。

[/编辑]

关于我所描述的已知协议或实现的任何想法？发送此数据有更好的主意吗？

我知道这个协议并不是很难设计，我想到了一个两阶段协议：

1）握手：发送您希望填写的所有表格的标题。每个表描述将包括有关每列大小的信息。

2）数据：发送表索引（根据握手），后面跟着实际数据。数据后跟校验和。

但我希望避免这种设计的小细节，并使用一些现成的协议。或者更好的是，使用可用的实现。

我有一个嵌入式设备，它保留了一个内表列表。我希望它将这个表的状态与一些外部数据库同步以进行调试。那就是每当我向某个结构数组添加元素时，我希望设备发出“INSERT INTO ...”命令。

但是，我通过 RS232 串行电缆发送数据，这使得发送显式 SQL 的开销无法接受。

由于我经常使用的 SQL 命令只有 3 种，所以我只能序列化这几种。即INSERT INTO,DELETE FROM和UPDATE。

我想到的一般想法是使用“压缩/可序列化”的 SQL 协议发送数据。我们不会将命令直接发送到 SQL 服务器，而是发送到我将编写的自定义序列化 SQL 服务器：

1. 我们将为每个更改数据库的简单操作（即 INSERT、DELETE、UPDATE）分配一个编号。唯一可用的可序列化 SQL 命令是INSERT INTO x (), DELETE FROM x WHERE id=y. 我们只能改变x和y。
2. 首先在服务器上创建所有必要的表一次。在服务器上保留一个哈希表，将每个表映射到一个数字。这可以在纯 SQL 中完成，因为这只完成一次。
3. 然后为每个表分配一个数字，确保服务器知道这个数字
4. 最后，每当我们希望执行 SQL 命令时，我们将发送命令号，然后是表号，然后是数据长度，然后是数据。服务器将通过表的描述来确定实际数据的布局。

例如

会被翻译成

和

会被翻译成

由于 id 被定义为单字节整数。

本着这种精神，是否有任何已知的协议/实现？

有没有人有更好的主意？