I’m glad it helps.  AFAICT a slow network actually _helps_ trigger the issue, 
guessing it allows the kernel TCP buffers to fill and leads to this issue.

Here is an older mono NetworkStream.Write, which was making up for the issue by 
continuing to push data through when the buffers filled:
https://github.com/mono/mono/blob/mono-3.12.1/mcs/class/System/System.Net.Sockets/NetworkStream.cs#L414

So I expect that will work around your issue, although it needs to be fixed in 
Socket.cs like the comments 
<https://bugzilla.xamarin.com/show_bug.cgi?id=43902#c3> in the bug.

> On Sep 19, 2016, at 6:12 PM, psant...@codicesoftware.com wrote:
> 
> Hi David,
> 
> Thanks for the info!!
> 
> So, does this fix the issue?
> 
>             while (sent < count)
>             {
>                 sent += mSocket.Send(buffer, offset + sent, count - sent, 
> SocketFlags.None);
>             }
> 
> Or am I simply having good luck??
> 
> I'm testing through VPN myself, so maybe the slow network helps. But, we are 
> able to see the same issue on LAN... always using the raspberry as server.
> 
> Thanks,
> 
> pablo
> 
> On 9/19/2016 23:38, David Curylo wrote:
>> Pablo,
>> 
>> I believe I’m experiencing a similar issue, also reported by others here: 
>> https://bugzilla.xamarin.com/show_bug.cgi?id=43902 
>> <https://bugzilla.xamarin.com/show_bug.cgi?id=43902>
>> 
>> Mono’s Socket.Send doesn’t block until all data is sent.  The old 
>> NetworkStream in mono used to account for this with a while loop to continue 
>> sending, but the NetworkStream from MS Reference Source expects the Socket 
>> to block until all data is sent.  When the reference source was pulled in, 
>> the Socket.Send could sometimes fail to send all the data.  I can’t ever 
>> make this failure occur on localhost, but it will occur for me communicating 
>> with remote hosts.
>> 
>> I’m working on a PR now to have Socket.Send_internal loop until all data is 
>> sent so Socket.Send will block as the reference source expects it to, unless 
>> anyone else has any suggestions.
>> 
>> -Dave
>> 
>>> On Sep 19, 2016, at 9:33 AM,  
>>> <mailto:psant...@codicesoftware.com>psant...@codicesoftware.com 
>>> <mailto:psant...@codicesoftware.com> wrote:
>>> 
>>> Hi,
>>> 
>>> I have found a potential issue with NetworkStream on ARM (Raspberry).
>>> 
>>> It might be a stupid bug on my code too, but I don't see it.
>>> 
>>> 
>>> In short: a simple multi-threaded server running on Raspberry (same 
>>> behavior on Mono 4.4.0 as Mono 4.6.0), client on W10:
>>> 
>>> 1. Fails to correctly send data using NetworkStream (server seems to send 
>>> the data, but it never arrives to 
>>> client).https://github.com/psantosl/mono-raspberry-socket-issue/blob/master/Program.cs
>>>  
>>> <https://github.com/psantosl/mono-raspberry-socket-issue/blob/master/Program.cs>
>>> 1.1. Fails *only* using NetworkStream (no BufferedStream or 
>>> BinaryReader/Writer around, and it still fails): 
>>> https://github.com/psantosl/mono-raspberry-socket-issue/blob/master-only-network-stream/Program.cs
>>>  
>>> <https://github.com/psantosl/mono-raspberry-socket-issue/blob/master-only-network-stream/Program.cs>
>>> 
>>> 2. Works correctly using Sockets (no streams on top). 
>>> https://github.com/psantosl/mono-raspberry-socket-issue/blob/master-use-socket-only/Program.cs
>>>  
>>> <https://github.com/psantosl/mono-raspberry-socket-issue/blob/master-use-socket-only/Program.cs>
>>> 
>>> 3. Works correctly using a custom NetworkStream:
>>> 3.1.  
>>> https://github.com/psantosl/mono-raspberry-socket-issue/blob/master-use-alternative-network-stream/Program.cs
>>>  
>>> <https://github.com/psantosl/mono-raspberry-socket-issue/blob/master-use-alternative-network-stream/Program.cs>
>>> 3.2.  
>>> https://github.com/psantosl/mono-raspberry-socket-issue/blob/master-use-alternative-network-stream/MyNetworkStream.cs
>>>  
>>> <https://github.com/psantosl/mono-raspberry-socket-issue/blob/master-use-alternative-network-stream/MyNetworkStream.cs>
>>> 3.3. Although I just saw it timing out after transferring several hundred 
>>> MB on each connection (I'm on a slow VPN connected to the Raspberry, 
>>> although we reproduced it on LAN too). Interestingly, using the regular 
>>> NetworkStream it fails inmediately.
>>> 
>>> 
>>> When it fails, what happens is that at a given point in time (in my tests 
>>> like in a few seconds) one of the client threads (or more than one) NEVER 
>>> exits the Read, data never arrives although the server log says the data 
>>> was written, but it doesn't. Since I've set a timeout for the read 
>>> operation, you see how the program stops working.
>>> 
>>> 
>>> 
>>> == Additional tests performed ==
>>> I tried with different buffer sizes, it always fails with the NetworkStream.
>>> 
>>> I ran the same server code on other setups:
>>> 
>>> * Window 10/.NET: OK.
>>> * OpenSuse 13.2 + mono 4.0.4 (Stable 4.0.4.1/5ab4c0d): OK.
>>> * Raspberry: failed both with mono 4.4.0 and mono-4.6.0.245 (built from 
>>> GitHub on the 746756c commit.
>>> 
>>> I originally discovered the issue running a Plastic SCM server on BananaPi 
>>> <http://www.bananapi.org/> (like a Raspberry + SATA).
>>> 
>>> == Extra notes ==
>>> * I know the multi-threaded server is not optimal and thread-per-connection 
>>> is really bad, this is just a test case.
>>> * Initially I thought we had an issue with async sockets, but after a few 
>>> days I just isolated the problem in NetworkStream.
>>> 
>>> 
>>> Any hints would be appreciated.
>>> 
>>> Thanks,
>>> 
>>> pablo
>>> 
>>> www.plasticscm.com <http://www.plasticscm.com/>
>>> _______________________________________________
>>> Mono-devel-list mailing list
>>> Mono-devel-list@lists.dot.net <mailto:Mono-devel-list@lists.dot.net>
>>> http://lists.dot.net/mailman/listinfo/mono-devel-list 
>>> <http://lists.dot.net/mailman/listinfo/mono-devel-list>
>> 
> 

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.dot.net
http://lists.dot.net/mailman/listinfo/mono-devel-list

Reply via email to