在WindowsAzure中实现TCP/UDP端口

我们希望通过Windows Azure云服务实现端口，并希望获得有关我们战略的一些反馈

我们目前的项目：

• 作为客户端运行的物理GPS装置
• 作为服务器运行的Windows Azure云服务

1） 物理GPS单元： 我们使用的是XT-4000[Xirgo Technologies]物理Gps装置，这是一种功能强大的跟踪、监视和控制网关设备。该设备需要UDP或TCP端口进行通信

2） Microsoft Azure云服务： 在这里，我们需要打开一个TCP或UDP端口，在那里有一个侦听器，并侦听设备[XT-4000]推送的传入数据

以下是我们认为我们的战略应该是什么。谢谢你的建议

• 正在Azure上创建TCP端口
• 设置侦听器以接收来自设备的传入信号

[但问题是，我们能否在Windows Azure云服务上创建TCP端口作为基于云的平台，如果是，那么如何创建？]

另外两个问题：

As the device supports both UDP or TCP port to communicate, which one is better?

• 由于设备支持UDP或TCP端口进行通信，哪一个更好

• 对于从设备到端口接收信号，我们是否需要任何第三方帮助

您需要使用而不是

对于云服务，您需要使用工作者角色来实现设备支持的协议。您可以选择TCP或UDP—无论您对编程更熟悉的是什么。你必须为你的云服务付费

至于其他问题：

As the device supports both UDP or TCP port to communicate, which one is better?

取决于设备支持的协议。我见过很多GPS设备使用的协议。从“只是发送并忘记”到“非常健壮的错误检查和接收确认”。如果您的设备的协议类型为“只发送并忘记”，那么TCP可能会更好，因为它更可靠。如果设备的协议容易出错，并且执行验证/CRC检查/接收确认，则可以使用UDP

为了从设备到端口接收信号，我们是否需要任何第三方 帮忙

---

这取决于您的编程技能…

我们已经在Windows Azure上成功实施了一项类似的服务（车辆跟踪）。一些意见：

• 根据astakov的回答，您正在查看一个云服务（工作者角色）
• Azure同时支持TCP和UDP，但如果您有选择，请选择TCP。UDP没有连接，设备无法知道您的服务是否已收到数据。我们被迫使用UDP，并且必须向设备发送确认数据，否则它会重新发送（我们实际上必须通过UDP编写自己的协议）。从服务器向设备发送UDP数据包可能会被移动网络防火墙规则（和其他网络配置）阻止。尽可能地对抗UDP-UDP的有损性质完全不适合车辆跟踪
• 检查设备是否支持DNS。其中许多设备只发送到IP地址，这使得部署有点棘手
• 这些设备需要尽量减少传输的数据（因为GSM数据成本），通常以专有和压缩格式发送数据。您的大部分工作将用于分离二进制数据。如果可以，请找到一家供应商，该供应商有一个库，您可以使用服务器端对数据进行解码。在我们的特殊情况下（对于定制设计和制造的设备），仅正确解码数据就花费了大约10个人月的开发时间

---

谢谢你的指导方针astaykov。@astaykov我不明白为什么“只发送就忘记”应该使用TCP，这基本上是UDP协议的定义。“不应该是另一条路吗？”克里夫，你为什么问我？！问问生产这种设备的人！但无论如何，我对这样的实现非常满意。Azure很长一段时间都不支持UDP，我很高兴通过TCP运行“fire and forget”类型的设备。我想知道在不知道GPS设备市场的情况下（显然）评论一篇8个月的帖子背后的驱动力是什么@astaykov好吧，不久前我选择了EC2而不是Azure，现在我了解了Azure，它支持UDP，并且在我使用UDP的实时系统时对它感兴趣。我显然误解了你的答案，因为UDP是火灾和遗忘通信的常见用法，但显然我对GPS系统的无知妨碍了理解。我很抱歉问这个问题。若设备不支持DNS，我不会说部署会更麻烦。Windows Azure保证只要有部署且您不删除它，IP地址就不会更改。就设备是否支持DNS而言，您部署云服务的方式绝对没有区别。现在，支持各种就地升级。