Is AllJoyn framework suitable for applications that require heavy network throughput ?

asked 2015-03-06 03:32:29 -0700

f_tocan gravatar image

I have noticed the windows implementation of socket does not use overlapped IO with completion ports which is the most performant on windows.
It uses WSAEventSelect and I wanted to test how much throughput I can obtain.
I used AllJoyn in a small sample that emulates screen sharing/file transfer sending 450 packets of 8KB every 30 ms which near close to 1Gbit.
I started with basic_client/basic_service sample (VS2013). Client runs on Win 8.1 64Bit and server runs on Win2012R2. Both machines are in the same local network and have 1GBit network card.

Client uses async version of MethodCall to send the packet, server method implementation does nothing and simply ignores the packet.
At this stage, I have not implemented any application flow control assuming the TCP layer will handle it.
The throughput was around 250Mbps.
After a while, in the client application the write timeout alarm is triggered and socket is closed.
Apparently no write event was sent by TCP layer to cancel the alarm.
My assumption was either client application is deadlocked and couldn't receive the event, either TCP didn't send the event.
All threads were in waiting state. Hard to tell if it was deadlocked or not.
I have analysed the network traffic with wireshark. In some cases there were a lot retransmissions, zero window followed by window update which looked normal to me.Also, there were some out of order packets which were presented as errors by wireshark.
Hard to say if it is wireshark's misinterpretation or indeed TCP couldn't recover from congestion errors. But I also had some cases where there was no error in wireshark.

After that I implemented a sort of flow control : not sending the N+1 packet until received MethodReply for the first packet.
For N=128 worked fine and the throughput was around 150Mbps.
For N=16 throughput was around 60Mbps.Worked for a couple of minutes then I observed the server method is not called anymore.
All threads in server application were in a waiting state.
Since packets reached the network (verified with wireshark) and wireshark shows no errors this time I suspect the server was deadlocked.
As a consequence no replay is sent to the client.Client waits for replay. No replay to MethodCcall could be observed with wireshark. The weird thing is that after a while the ReplyHandler is called with a Message with 0 args. Memory from that message looks messy.Therefore trying to extract the arguments causes the client to crash.

So I wonder if I misused the library or if it was not designed for these scenario or if these are real bugs.
Thanks in advance for any help.

edit retag flag offensive close merge delete


you might try on the core mailing list.

ry.jones ( 2015-10-15 08:53:30 -0700 )edit