Multicast Programming
-
I am writing an app that needs to receive multicast data. However, the amount of data being sent on a single multicast group is enormous and I do not have any control over the publishing side of the data. So what I'd like to do is to run multiple instances of the same app on a single, high power machine and assign each instance of the app a manageable segment of the total multicast feed to process. So for example run 4 apps and let each of them process only 1/4 of the total amount of data each. But here is the problem, which I hope one of you will be able to help me solve. If I run multiple instances that all try to join the same multicast group on the same machine I get the following error: System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted This happens when the UdpClient object is being instantiated as follows: udpClient = new UdpClient(portNumber); The interesting thing is that I do not have this problem when I run an app that was built using Visual C++ and WinSock. It only happens with the .NET framework. Does anyone have an answer to this other than "use 4 separate machines"? Thanks Robert
-
I am writing an app that needs to receive multicast data. However, the amount of data being sent on a single multicast group is enormous and I do not have any control over the publishing side of the data. So what I'd like to do is to run multiple instances of the same app on a single, high power machine and assign each instance of the app a manageable segment of the total multicast feed to process. So for example run 4 apps and let each of them process only 1/4 of the total amount of data each. But here is the problem, which I hope one of you will be able to help me solve. If I run multiple instances that all try to join the same multicast group on the same machine I get the following error: System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted This happens when the UdpClient object is being instantiated as follows: udpClient = new UdpClient(portNumber); The interesting thing is that I do not have this problem when I run an app that was built using Visual C++ and WinSock. It only happens with the .NET framework. Does anyone have an answer to this other than "use 4 separate machines"? Thanks Robert
goodpilot wrote: Does anyone have an answer to this other than "use 4 separate machines"? Yes - don't use multiple processes. Multiple processes will not necessarily solve the problem and will most likely add to it. Each process has significant overhead: it's own process space, handles, thread queues, and in this case a separate instance of the CLR loaded. The common, "more correct" approach would be to use worker threads. You can either use the
Threadclass or theThreadPool.QueueUserWorkItem(recommended; read about thread pools in theThreadPoolclass documentation) to split the work. You could even make this configuration at launch time using the .config file for the application. This will use significantly less memory, cause the CPU to perform better in regard to your application (it's not switching to time-slice between multiple applications - on threads), and give you greater control...not to mention solve your problem (since one process is listening to the socket). So, all data would be received by theUdpClient(it would anyway - you're just processing in chunks). Just chunk the data to one of N number of worker threads. This is actually how most socket servers work that you'll find any information about, and they can service hundreds or even thousands of connections.Microsoft MVP, Visual C# My Articles
-
goodpilot wrote: Does anyone have an answer to this other than "use 4 separate machines"? Yes - don't use multiple processes. Multiple processes will not necessarily solve the problem and will most likely add to it. Each process has significant overhead: it's own process space, handles, thread queues, and in this case a separate instance of the CLR loaded. The common, "more correct" approach would be to use worker threads. You can either use the
Threadclass or theThreadPool.QueueUserWorkItem(recommended; read about thread pools in theThreadPoolclass documentation) to split the work. You could even make this configuration at launch time using the .config file for the application. This will use significantly less memory, cause the CPU to perform better in regard to your application (it's not switching to time-slice between multiple applications - on threads), and give you greater control...not to mention solve your problem (since one process is listening to the socket). So, all data would be received by theUdpClient(it would anyway - you're just processing in chunks). Just chunk the data to one of N number of worker threads. This is actually how most socket servers work that you'll find any information about, and they can service hundreds or even thousands of connections.Microsoft MVP, Visual C# My Articles