Peer Channel performance

Hi all!

I am building a p2p application using WCF and the peer channel and one of the requisites of this application is to be able to send the higher number of updates per second. While doing some profiling, I noticed that server was sending (at least the sending method executed and returned) at the rate I had specified but clients were receiving at a variable rate. For instance, I specified an update rate of 170 miliseconds on the server and logs said it was sending more or less at that rate. But the logs on the client side were different: they showed a quite variable receiving rate (i.e. 171, 12, 189, 12, 231, 11, 171, 12, 232, 12, 187, ...), it seems as there was some kind of buffering that waits till having a pair of messages before doing the real sending.

Of course there is some computing work on the client side, but they are around a few miliseconds on a separate thread from the receiving process. Then I looked for some answers on the net and I met a post on Kenny Wolf's blog, http://kennyw.com/indigo/51, that talks about the channel property MaxBufferPoolSize. I have tried his recommendations (to assign 0 to MaxBufferPoolSize) but without the expected results. Also I found on MSDN that "The value of MaxBufferSize cannot be less than MaxMessageSize whose default value is 65536 bytes (64 KB). "(MSDN link).

Anyone solved something similar Any advice/clue

Answer this question

Peer Channel performance

Richard oupatty
Thanks Ravi, Adiavn, Oran and Kenny for your comments and I apologize for the time you spent thinking of my problem. I am sorry for the time passed without posting anythimg but I was doing other things.

I have managed to solved this week the extrange behaviour I was experimenting and it had nothing to do with Peerchannel. David Pallman's post and his performance results made me look at my code again and I finally found 2 mistakes in 2 very simple pieces of code. Now, sender is able to send an update message every 20~25ms and receiver can consume and process the messages without noticeable delays.
NewDeveloper83291
I didn't mean the size of the serialized object. I meant any application level payload you were inserting into the message itself. Do you have any
Olle Gustafsson
Very interesting! From what I can gather, you are sending data every 170msec, is this correct

Could you tell us what the size of your messages is
Ahmed Rob
The payload is around 500 bytes per message.
Ivan Jou
Hi Ravi,

You are right, I am sending data to clients at 170msec. Regarding the size of the message, do you know how to query that I mean, how could I query the size of serialized object and not the size of the "local" object
I have used several times E2E logs but the message size column always shows N/A.

Thanks in advance.
Amy T
Did you check all of the messages in the clients were different from each other

Since in p2p clients are also broadcasting, coulding it be possible the first message originated at the server, while the second was a duplicate from another client
SkypeDeveloer
I'm guessing you're running into TCP's Nagle algorithm that buffers data for up to 200 milliseconds if TCP thinks it doesn't have enough data to fill up a packet. This makes TCP less chatty at the IP level and gives higher throughput for large data transfers, at the expense of responsiveness. Telnet and other "real-time with small data" users of TCP disable the Nagle algorithm. In .NET 2.0 this can be disabled with Socket.NoDelay for TCP sockets. I'm not sure where this is configured on the peer channel.

You may want to consider using UDP if timing is really important to you, assuming you can tolerate packet loss or write your own reliable UDP solution (MSDN Mag had an article on this recently). Otherwise you will be at the mercy of a variety of other TCP-isms such as Slow Start, the connection handshake, retransmission of dropped packets, buffering due to out-of-order delivery, congestion avoidance, etc. Some of these things you won't see when testing on a LAN but they will seriously bite you on a high-latency or lossy network.

Oran
vichu
I'm having facing a very similar issue while sending out messages over TCP sockets. Could you please point me to the proper url or code snippet that solved your problem. Thx Jaydip
hye_heena

Do you have AllowOutputBatching = true This would affect your TCP latency.

http://kennyw.com/indigo/49
Bruce Voris
Hi Adiavn,

Right now I am debugging with only 1 client, therefore I think that is not possible (or am I wrong and that is possible with the Jan CTP and using the provided custom peer resolver ).

Thanks for posting your thoughts.
Peer Channel performance

Answer this question