[Mono-bugs] [Bug 75526][Nor] Changed - StreamReader blocks on reading too much

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by gnauck at ag-software.de.

http://bugzilla.ximian.com/show_bug.cgi?id=75526

--- shadow/75526	2005-08-30 04:19:49.000000000 -0400
+++ shadow/75526.tmp.23823	2005-08-30 05:48:05.000000000 -0400
@@ -128,6 +128,26 @@
 In the case of http://xmlrpccs.sourceforge.net I now fixed the problem
 by copying the contents of the network stream (lenght is known because
 of the Content-Length field of the POST request) into a string and
 using this as the buffer to read from (in which case the end of stream
 is recognizable).
 
+
+------- Additional Comments From gnauck at ag-software.de  2005-08-30 05:48 -------
+Daniel,
+
+yes its exactly the same in my application
+(http://www.ag-software.de/content/agsxmpp). Im parsing xml from XMPP
+streams. In my XML Parser i was always reading X bytes from the
+network stream. X is variable and could be set by the programmer. So
+when X is set to 1024 then i try to read 1K into a buffer for
+XML-parsing and stuble exactly into the same problem as you. When less
+then 1K of data is available in the network stream, it blocks until it
+can read 1K. Because XMPP is not HTTP based and i have no content
+length the only solution for is to set X on MONO to 1 and read the
+network stream byte for byte. In this situation it blocks only when no
+data is available, and returns when more data is availble.
+
+So its not really a bug. Its only a different behaviour. Our projects
+noth rely on the MS .NET design, and i assume lots of other projects
+too. So it would be very good when the MONO Streams have the same
+behaviour and design here than the MS Streams.