Hello Guys,<br><br> We are using winpcap (4.1.0.1753) to handle a huge RTP packets traffic being sniffed from an Audio Gateways of my company. Our application has the ability to persist specific RTP packets to Hard-Disk (we get the IP Addresses and Ports information to filter these data from our application).<br>
<br> Our tests were executed in a Windows 2003 Standard Edition x64 (64
Bits) server, Intel Xeon E5520 2.27 Ghz & 6.00 GB of RAM.<br><br> We have noticied that we are getting peaks of RTP packets traffic corresponding to 25 concurrent calls (G.711 codec) from this Audio Gateway. Based on our notes, the current traffic being spanned is quite lower than 1 MByte per second.<br>
<br> Our application starts and opens the interface which is getting the mentioned traffic and sets the interface's filter as "udp". Later, we are filtering (from our application) the IP Addresses and Ports needed to be persisted. In our current test, we are just saving one call in the Hard-Disk (only two sniffed RTP packets flow) with a different Thread-Pool. Thus, we are receiving peaks of 25 concurrent calls, but a different application thread is saving just 1 call to Hard-Disk.<br>
<br> The problem is that we are experiencing several packet losses of several seconds each in this persisted call. We checked that Wireshark is not loosing so many packets. Thus, we tried to increase our winpcap kernel buffer to 4 Mbytes, 10 Mbytes, 500 Mbytes. In all cases we detected a performance improvement, but we are still having packet losses (2 seconds more or less sporadically with a kernel buffer of 500 Mbytes) :(.<br>
<br> Our application is developed in C# .NET 3.5 and wrapping the Winpcap APIs. Our application's piece we are putting our eyes to is when Winpcap invokes the wrapped C# Callback. From that point we are creating a couple of C# objects in order to turn the unmanaged winpcap structures into C# managed objects. After that, we are enqueueing these objects in an own circular buffer and then another thread-pool is unbuffering this information. We have figured out that our circular buffer is not discarding any packets.<br>
<br> Our big concern is that currently we are experiencing Winpcap issues in our application which has peaks of 25 concurrent calls, and if we think that we might get peaks of 200 concurrent calls in the future, I'm not sure that some application's performance improvement will make a big difference than today's performance. We think that maybe a better approach would be to open several times the sniffed interface and, for each one, sets the respective IPAddresses and Ports' filter. <br>
<br> Based on what I've told you, we want to know your opinion:<br><br> a) Do you think the fact of opening several times the same interface and setting better filters will be a good approach? <br> b) How many concurrent winpcap handlers (for one interfaces) we may have opened at the same time?<br>
c) We think that if we open the interface several times there will be several winpcap kernel ring buffers. What size do you think would be the best for each of these kernel ring buffers? If we think in having Kernel ring buffers of 5 MBytes, and 200 concurrent calls, we would need 1 GByte of memory dedicated to Kernel Ring Buffer. This memory requirement is not a problem anyways.<br>
d) Do you think that we should concentrate our effort in trying to improve our application's performance? We are just creating C# objects... That shouldn't consume much time.<br><br><br>Thanks in advance for your help.<br>
Damian Nardelli - C/C++/.NET Software Developer.<br><br>