PeerChannel message loss and more test data

Here's the latest in my attempt to find a reliable configuration for PeerChannel to handle large volume enterpries messaging, and some new test results.

When I first started playing with PeerChannel, it seemed like it lost messages very easily. Then I found that by adding an Application.DoEvents or a small sleep in my tight sending loop, things got better. A lot better: a couple of days ago I posted test results where I never lost a single message. If I really pushed things and tried to send a million messages, receivers eventually ran out of memory, but the network and its buffering were superb. Not a single lost message. That testing was perforrmed on Neudesic's network. Now it was time to try it at a customer.

This week, I've been testing at a large enterprise customer in the financial industry with a very busy network. The results are quite different and we're experiencing a lot of message loss. In the test results below, increasing the sleep time in the sender loop eventually gets to a stable point where there is no message loss by any of the receivers, but at a dramatic cost in message throughput. For 100-byte messages, a 35 ms sleep between sends seems to be the magic number. But it's not much of a consolation, because changing any of a number of variables takes you back into a message loss situation. For 1000-byte messages (see last two results below), I went back into a message loss condition even with a 50ms wait between sends.

My questions:

(1) Is this kind of message loss normal or abnormal Prior dialog on this forum seemed to indicate that the team expected no message loss generally, but I'm seeing plenty of it. What might explain this phenomenon

(2) How can I detect how busy a PeerChannel network is, and/or what throttling controls are available to prevent senders from flooding the network Being able to monitor and regulate the throughput rate seems paramount.

(3) Are there best practices for ensuring good network throughput you can point out, so we can make sure we're following them

Thanks,
David