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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
