实时会议/共享视图（例如 Azure 上的实时屏幕共享服务）？
在 Windows Azure 上构建实时屏幕共享服务（有些接近共享视图或实时会议）可能需要考虑哪些因素？请分享您的想法。
为此，显然我们必须创建一个自定义 TCP/IP 服务器 - 客户端可以通过 TCP/IP 之上的自定义协议连接到该服务器并实时交换（发布/检索）数据。
我认为 Azure 目前仅在端口 80 和 443 上支持 Web 角色的 TCP/IP？请分享您的想法。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
哇 - 快 2 岁了，还没有接受的答案！正如 Joannes 所说，实时将是一个挑战 - 您需要仔细评估这在响应时间和延迟方面对您意味着什么。
自从您提出这个问题以来，Windows Azure Worker 和 Web 角色已经发生了很大的变化。现在，您的部署中最多可以有 25 个输入（例如面向外部）端点，分布在 Web 和辅助角色的任意组合中 - 您定义端口号 - 不限于 80 和 443。您还可以有最多 25 个内部端点（用于角色间通信）。
设计在 Windows Azure 中运行桌面共享服务与设计 Windows Server（这就是 Windows Azure VM 正在运行的内容 - Windows Server 2008 R2）时具有相同的基本注意事项。您需要通过自己的自定义解决方案或可能使用访问控制服务来处理身份验证和授权。
好的，您需要记住一件事：Windows Azure VM 是无状态的，您不应该假设用户将始终连接到同一个 VM 实例（无法直接访问特定实例） Web 或 Worker 角色）。因此，您需要外部化任何类型的特定于会话的数据（这非常容易，SQL Azure 和 Windows Azure 缓存服务都非常容易设置并用作会话提供程序）。
Wow - almost 2 years old and no accepted answer! As Joannes stated, realtime is going to be a challenge - you'll need to carefully evaluate what that means to you in terms of response time and latency.
Windows Azure Worker and Web Roles have evolved considerably since you asked this. You can now have up to 25 input (e.g. external-facing) endpoints in your deployment, spread across any combination of Web and Worker roles - you define the port #s - you're not limited to 80 and 443. You may also have up to 25 Internal endpoints (used for inter-role communication).
Designing to run a desktop-sharing service in Windows Azure would have the same basic considerations as when designing for Windows Server (that's what the Windows Azure VMs are running, afterall - Windows Server 2008 R2). You'll need to deal with authentication and authorization, through your own custom solution or possibly with Access Control Services.
Ok, there "is" one thing you'll need to keep in mind: Windows Azure VMs are stateless, and you shouldn't assume a user will always connect to the same VM instance (there's no way to direct-access a specific instance of a Web or Worker role). So, you'll need to externalize any type of session-specific data (which is very easy, with both SQL Azure and Windows Azure Cache service both very simple to set up and use as session providers).
对于云计算提供商来说，低延迟仍然是一个棘手的问题（Azure 也不例外）。我认为这将是设计中最困难的部分。然后，自 2009 年 11 月发布以来，辅助角色也可以有入口点（但不确定端口限制）。
Low latency is still a tough case for cloud computing providers (Azure being no exception). I think that's going to toughest part in the design. Then, since the Nov'09 release, worker roles can have entry points too (not sure about port limitations though).