HttpWebRequest AllowreadStream缓冲属性在蜂窝网络上不受尊重？

我正在编写一个应用程序，它使用http上的持久连接——也就是说，web服务器永远不会完成对响应流的写入，客户端应用程序在响应流进入时从响应流中读取数据

我编写了一些.NET3.5桌面/winforms应用程序来确认服务器和客户端代码是否有效，然后编写了一个WindowsPhone应用程序来执行同样的操作。桌面/电话代码之间的唯一区别是我在电话上将AllowReadStreamBuffering属性设置为false

该手机应用程序昨晚工作，但今天不工作-当尝试读取响应流时，它将挂起，直到从服务器端关闭连接-这意味着HttpWebRequest不遵守AllowreadStream缓冲设置

昨天晚上和现在的区别在于，昨天晚上，我使用的是wifi，而今天，我使用的是手机连接

我的假设是，在手机上，当连接是wifi或以太网时，HttpWebRequest只接受AllowReadStreamBuffering=false，但在使用蜂窝网络时，HttpWebRequest会忽略AllowReadStreamBuffering=false

那么HttpWebRequest在通过蜂窝网络连接时强制读取流缓冲是真的吗？我还没有找到任何证实这种行为的文档，所以我想知道是否有其他人经历过这种情况。稍后我将能够更彻底地测试这一点，但现在我想我应该问这个问题

更新5-11-12

---

测试并回答了我自己的问题（见下文）

AllowReadStreamBuffering=false在蜂窝连接上是值得尊敬的；否则，例如音频流应用程序将无法正常工作。

我验证了我的WP7应用程序在通过蜂窝网络连接时，最初不会读取未缓冲的响应流-它仅在以太网或wifi上读取响应流

因此，我修改了我的服务器httphandler，在连接开始时将一个初始数据块8k写入响应流。这样做可以让应用程序立即在手机上读取响应流，就像在wifi上一样。在忽略了最初的数据爆炸后，应用程序实时处理单个字节

---

我能想到的唯一结论是，当通过蜂窝网络连接时，HttpWebRequest最初需要缓冲少量数据，然后才能允许无缓冲地读取流。

我的服务器每秒发送1个字节，客户端在服务器关闭流之前不会通过蜂窝网络打开响应流。这是否意味着在开始响应激发之前，可能有一个最小的接收数据大小？可能是服务器没有正确刷新，或者应该启用分块传输，以获得更合适的长期连接支持。我将尝试服务器端更改，但该应用程序在wifi上工作，而不是在蜂窝网络上工作，这一事实让我认为这是一个.NET framework问题。