Microsoft Exchange引入了流式通知，作为使用Exchange 2010提取/推送通知的替代方法。有关流媒体的基本介绍，请参阅此msdn article和blog
但是，我无法弄清楚流式传输推送通知的实际优势。 博客中提到的唯一优势是“..并且您不必像推送通知一样创建监听器应用程序。”除此之外，还有其他优点和缺点吗？ 管理订阅，重新订阅逻辑，可扩展性，最大订阅数量等其他因素如何比较推送？此外，Streaming订阅的最长活动时间为30分钟，我必须每30分钟重新订阅一次？不是大量订阅的缺点（我的应用程序必须管理20K +邮箱）？
对比较因素的任何启示都会有所帮助。
答案 0 :(得分：5)
流式传输通知（SN）的主要原因是Exchange Online。您不能让EOL打开与可能位于防火墙后面的应用程序的HTTP连接。即使在企业网络中也存在防火墙问题。我有几个案例，由于自己的服务器上有防火墙，我的应用程序无法获得推送通知（PN）。
从表面上看，SN似乎也更有效，因为每个通知都没有打开自己的TCP连接，而是在一个管道上流入。在对此进行了一些Wiresharking之后，我并不是真的相信这是因为它看起来像是在进行Long Polling，所以每次进入的通知都会导致新的HTTP回调到Exchange。
30分钟的最大值没什么大不了的，只需重新打开处理程序中的连接就可以了 - 你不需要实际重新订阅。事实上，我认为我想降低甚至更多说3分钟。您显然无法添加新订阅或删除旧订阅，除非在断开连接处理程序中。 （尝试一下，就会出错。）
是的，您不必编写HTTP处理程序，我猜这很好。