Single source pushing: how to send 5kb each 5 minutes to 50000 clients

I need to implement a client server architecture where the server sends the same message to many clients over the internet. I need to send a single message every 5 minutes about. The message won't excede 5KB. I need the solution to scale to a big number of clients connected (50.000-100.000)

I considered a bunch of solutions:

• TCP Sockets

• UDP Multicast

• WCF http duplex service (comet)

I think I have to discard UDP solution because it is a good solution only for clients on the same network and it won'开发者_C百科t work over the internet. I read somewhere that WCF multicast will cause a bottleneck if I have many clients connected but I can't find anywhere documentation showing performance statistics. Tcp sockets seems to me the solution to chose. What do you think about? Am I correct?

I'm certainly wrong when I say UDP doesn't work on internet... I thought this because I read some articles pointing out that you need properly configured routers in the network to support multicasting... I read of the udp ports multicast range and thought it was meant to be locally. Instead, the range 224.0.0.1 - 239.255.255.255 (Class D address group), can be reached over the internet

Considering that in my case reliability is not a crucial point, the udp multicast is a good choice. The .net framework offers really helpful classes to accomplish this. I can easily start an UdpClient and begin send data on a multicast address with two lines of code. At client side it is really easy to. There is the UdpSingleSourceMulticastClient class that does exactly what I need. For what concernes reliability and security the .net framework has a smart and simple way of handle DoS attacks, DNS Rebinding attacks and Revers tunnel attacks that is described here: http://msdn.microsoft.com/en-us/library/ee707325(v=vs.95).aspx

The main question is: Do you care if the updates get to the clients?

If you DO then you will need to build something on top of UDP to add reliability. UDP datagrams are NOT reliable and so you should expect that some wont get to the destination. This is more likely if you are pushing UDP datagrams out quickly. Note that your clients might also get multiple copies of the same datagram in some situations with UDP.

50-100k connections with this level of traffic shouldn't be that difficult to achieve with TCP if you have a decent architecture.

See here for some blog posts that I've done on the subject.

• http://www.serverframework.com/asynchronousevents/2010/10/how-to-support-10000-concurrent-tcp-connections.html

• http://www.serverframework.com/asynchronousevents/2010/10/how-to-support-10000-or-more-concurrent-tcp-connections---part-2---perf-tests-from-day-0.html

• http://www.serverframework.com/asynchronousevents/2010/12/one-million-tcp-connections.html

And here's some example code that deals with sending data to many clients.

• http://www.serverframework.com/ServerFramework/latest/Docs/examples-datadistributionservers.html

Unicast (tcp sockets) will work fine for a relatively small amount of traffic such as this, but keep on top of multicasting technology, the situation is changing every year.