1

我正在使用 cURL 连接到由 Gnip 公司管理的服务器。(www.gnip.com) 最终我们希望无限期地使用管道 json 提要。

最初，当我设置我们的软件时，编写了一个很好的小类来维护连接；它是通过 gnip 从社交网络提供的。

Gnip 改变了他们要求完成连接的方式，因此课程中断了。

我可以很好地连接到服务器。有时它会保持打开状态数天，有时连接会在几秒钟内断开。

一切应该工作的方式是：我连接到 gnip 并保持一个开放的连接。gnip 将数据作为 json 字符串实时发送给我（当他们收到时）。如果在 30 秒内没有发送任何数据，他们会发送一个“保持活动”信号，让我的脚本知道它仍然处于连接状态。

理想情况下，脚本只会在两台服务器之一关闭时断开连接。我已经通过 cronjob 处理了这个问题。

问题是连接有时会意外关闭。我联系了 gnip，他们的日志说断开连接不是他们的错。

这一切都超出了我的正常范围。我确定 curl 正在发送某种错误，但我不知道如何找到它以记录它。

这是我到目前为止编写的代码的副本：http: //pastebin.com/jpHzvbTF

我喜欢直接的“这是你解决它的方法”，但我也很想知道一些要阅读的术语，这可能会导致我找到自己的解决方案。

我已经阅读了 curl / php 中的 Keep-alive，但我发现它与建议的时间并不相关。

4

1 回答 1

2

我在一家公司工作，该公司是 Gnip 的客户，使用的产品与您使用的相同。我们的代码是 Java，而不是 PHP，所以我可能无法为您提供很大的帮助，但这是我在使用这些提要时发现的：

  1. 流式 HTTP 并不是人们想象的那样。在您所在的位置和 Gnip 端点所在的位置之间可能会出现很多问题。
  2. 您将需要构建逻辑来检测断开连接并尝试重新连接。同样，我不确定您将如何使用 cURL 和 PHP 来执行此操作。在 Java 中，对我们有用的是输入流上的读取超时和连接超时以强制异常，因此我们断开连接并重试，但您也必须小心这些 - 太短的 TCP 读取超时会看到您不断地重新连接，这会在 Gni​​p 的 UI 中产生非常奇怪的行为。然而，使用这样的东西可以让你捕捉到 Gnip 未能发送他们的 keep-alive 换行符并适当地循环你的连接的状态。
  3. Gnip 会定期更新他们的软件，并在他们的条款中说明这一点。在这些更新期间，他们可能（将）断开您的连接，您需要重新连接。除非它们的末端有错误，否则此断开通常会发出正确的信号并且不会使您的连接处于不良状态，因此无论您用来检测断开的连接是否会触发，您可以重新连接，一切都很好。

我希望我能给你更好的建议，告诉你如何处理你所使用的特定技术所遇到的问题。稍微深入研究一下流式 HTTP（或 Keep-Alive HTTP 会话），看看这是否能让您无所适从。一定要弄清楚如何捕获任何类型的断开连接，然后重新连接。

Gnip 已经开始建议人们实现重新连接退避逻辑，这意味着您的重新连接将立即开始，并且在每次连续重新连接失败时，等待 n*2 < 10（例如）秒，其中 n 是连接数迄今为止的尝试，然后重试。Twitter 自己要求将其作为其流媒体服务的一部分，而 Gnip 只是建议这样做（毕竟这是一项付费服务​​），但如果你想让你的 Gnip UI 不因尝试失败而变得混乱，我会推荐它。

在大多数情况下，我对 Gnip 的体验非常好。但是流式 HTTP 是一种非常不完美的技术（正如我们已经发现的那样）。有一种有点幼稚的想法，即您可以连接一次并从此过上幸福的生活。刚开始的时候我也觉得会是这样，现在我有点愤世嫉俗了。如果我有我的 druthers，我将永远不会支持构建在 Streaming HTTP 之上的生产系统以及我自己网络之外的服务。我宁愿获得 FTP 丢弃，因为对于您可能正在谈论的那种卷，这一切都是一件令人头疼的事情。不幸的是，该产品线不提供它们。

祝你好运。

于 2012-07-07T20:14:47.040 回答