<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Hello,<BR> <BR>From your experience, what is the best approach for a service using WinPcap to read/write raw packets at high speeds (Gbps or more).<BR> <BR>I'm P/invoking from .NET.<BR> <BR>For reading, I am currently using a single thread that invokes pcac_read_next_ex in a loop and copies the bytes (with Marshal.Copy) to a ring buffer. Another single thread converts those individual reads left in the ring buffer into TPL tasks to process the individual messages in managed thread pool threads, allowing multithreaded processing. I use a -1 timeout and switch to a wait on the result of pcap_getevent when a certain amount of consecutive reads don't yield a message. That way I limit CPU comsumption in that case.<BR> <BR>For writing, I would like to be as multithreaded as possible, having into account that messages to be written are produced concurrently by multiple threads. If each thread can call pcap_sendpacket right away, and use the pinned buffer it already owns, I think the global performance must increase.<BR> <BR>I'm aware that a single pcap_t contains certain resources that are not directly shareable by different threads (e.g., an errbuf). So I think I cannot reuse for writing the same pcap_t (from pcap_open) used for reading.<BR> <BR>Furthermore, I think I cannot open a second pcap_t and use it for writing from several threads concurrently (for the same sharing problem).<BR> <BR>One approach to do it would be to use Threading.ThreadLocal<T> in .NET. It gives a different instance of T per thread.<BR>If I build a managed wrapper over pcap_t, initialized in every writing thread to the result of a new pcap_open (independent of the pcap_open for reading), and provide a destructor to conveniently recycle the pcap_t in case of thread destruction, I can have a convenient mechanism to have a different pcap_t per writing thread.<BR> <BR>But what about global resources consumed by this approach? I plan to use thread pool threads to write (potencially a big number). How many resources does a pcap_t hold? Imagine multiplying it by 1000 or more.<BR> <BR>Can an "only for writing" pcap_t be made tiny in resource consumption compared to a reading capable pcap_t or else will it also spend kernel buffers, capture all packets again even if no one will ask for them, etc.? I find prohibitive having 1001 pcap_t's, each consuming 1 MByte kernel buffer and capturing the whole stream of bytes from the NIC.<BR> <BR>But, at the same time, synchronizing writes in my service to perform them with a single thread if the driver already perfoms that synchronization or it is avoidable is a wasteful expense of resources.<BR> <BR>Thank you very much.<BR> <BR>Regards,<BR>J.M.<BR>                                     </div></body>
</html>