My problem is that I can't find any documentation on how to do this using the UDP transport sample. Any ideas or suggestions?
Thanks.
Bruce Bukovics
You need to change the UdpChannelListener.CreateSocket implementation to the following:
Socket CreateListenSocket(IPAddress ipAddress, int port) if (multicast)
{
bool isIPv6 = (ipAddress.AddressFamily == AddressFamily.InterNetworkV6);
Socket socket = null;
{
IPAddress anyIPAddr = IPAddress.Any;
if (isIPv6)
anyIPAddr = IPAddress.IPv6Any;
IPEndPoint endPoint = new IPEndPoint(anyIPAddr, port);
socket = new Socket(endPoint.AddressFamily, SocketType.Dgram, ProtocolType.Udp);
socket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, 1);
socket.Bind(endPoint);
if (isIPv6)
{
socket.SetSocketOption(SocketOptionLevel.IPv6, SocketOptionName.AddMembership,
new IPv6MulticastOption(ipAddress));
}
else
{
socket.SetSocketOption(SocketOptionLevel.IP, SocketOptionName.AddMembership,
new MulticastOption(ipAddress));
}
}
else
{
IPEndPoint endPoint = new IPEndPoint(ipAddress, port);
socket = new Socket(endPoint.AddressFamily, SocketType.Dgram, ProtocolType.Udp);
socket.Bind(endPoint);
}
return socket;
}
This implementation will be available in the next release
Bruce Bukovics
Author of .NET 2.0 Interoperability Recipes
http://www.apress.com/book/bookDisplay.html?bID=10116
Hi, Bruce
How is your multicast? does it work? im trying the sample according to Ed Pinto 's code but have no clue how to configure the multicast work.
I assume you need to set the Multicast = "true" in some where, right?
what i want is one client app send a message and all other client apps(listeners) should receive base on this Udp multicast.
Very much appreciate if you could share your ideas.
thanks a lot
My current projects have been pulling me in other directions. I plan to revisit this soon.Bruce
Thanks. i have tried it with Beta and modified a bit of it so it works for me now.
Would love to share if anyone interested.
Be warned the UDP sample implementation is significantly slower than the nettcp implementation ( i have seen 3* slower) and nearly as slow as the http/ws bindings. When queried with some times it was stated it is not optomised ( It would have been nice if the sample showed you how to build a fast transport) . If you had >30 clients on 1 network segment ( subnet) , id consider multi cast but otherwise id just use multiple tcp conversations.
Regards,
Ben
I've had a quick look at the UDP sample and like Oaix I cannot instantly see how to configure multicast. Also I compiled the sample ok but it hangs on the first socket close. I am running .Net 3.0 RC1. Oaix can you post an update of your experience. In particular info on:
- How to configure multicast + any sample code you want to share.
- How well udp works in practice. I mean can the sample be considered to be production grade? Another contributor said it was slow and needed optimizing (how?).
- How far you got in using net.msmq multicasting.
My primary concern is reach rather than performance. I want to multicast to clients across domains in the extended corporate intranet (and possibly remote clients over the Internet) with the minimum fuss. I figured net.msmq using srmp would be the best offering out-the-box? All comments appreciated.
Ben is right. have tested in Tcp with 20 clients within a LAN and the result is really satifying.
The sample i modified is base on June CTP but i guess it should work with RC1 too.
I did it without consider the performance. right now we are using MSMQ multicast instaed of UDP for more clients. would love to hear from anyone who has tried it with UDP and its performance.
leave me a e mail addr so in can send the whole sample to you.
Thanks oaix
- Does your app multicast across multiple domains?
- How does the UDP version compare vs. TCP and MSMQ in your tests?
- Are you using msmq or net.msmq?
- Does your app automatically switch to msmq when the number of active users hits a threshold?
- Please send sample to webmaster<"at">infosecurityproducts.com
- Does your app multicast across multiple domains?
Yes. thats part of the requirement.
- How does the UDP version compare vs. TCP and MSMQ in your tests?
We haven't do the comparaion, as i said the UDP only for POC to know that muticast works with modify the sample.
- Are you using msmq or net.msmq?
We are using msmq for multicast, so it has to be msmqintegration
- Does your app automatically switch to msmq when the number of active users hits a threshold?
No, we use msmq to distribute data (multicast) that change very freqently for many clients
- Please send sample to webmaster<"at">infosecurityproducts.com
give me 1-2 days. need to find teh sample and try to make it work with RC1. which make more sense i guess
Oaix
Thanks for the info and the offer to package your sample. In actual fact, please don't worry about it. I have pretty much decided to use msmq - basically because it is simpler - and I don't want to waste your time.
Ben. I am essentially implementing a pub-sub pattern, the issue is which transport to use. I have bookmarked an interesting ws-eventing article I found on CodeProject I intend to read soon. I need to multicast because my app publishes a lot of live data updates. Clients can be in the service domain, another domain within the corporate intranet, or a remote business partner domain. I need an Http transport because there can be firewalls between any client and the service.
net.msmq with SRMP looks like a good bet, but because it requires both ends of a channel to have IIS I think I have to create a store and forward director to go at the client domain boundary. The director would multicast to clients on the local domain.
as a matter of fact, we are using WS-Eventing for the pub/sub right now. so far looking very good. as for our case, the live data we use msmq multicast for the quick deliver but we allow this type of date 'lost' once a while. some 'must' deliver data we use tcp/ip in LAN (so far) . so far so good.
I am still not totally comfortable with msmq as a multicast delivery mode for a ws-eventing/pub-sub design pattern. A fundamental concept of pub-sub is that the subscription part should be dynamic. Clients should be able to subscribe and unsubcribe to any number of topics on the fly. With msmq, IP multicast is achieved by configuring a queue with a multicast address so each topic has to have a dedicated queue. What's more it is most likely that the subscription manager will have to create create queues on demand. So for example if you had a global stock price system that lets clients subscribe for price updates by individual stocks you would have to create a queue for every stock in the known universe.
That seems impractical if not impossible. The workaround is to restrict subscription scope to a higher level e.g. US stocks, European Stocks etc and transfer the burden of filtering to the client. That is all well and good, but it goes against the objective of pub-sub.
I have read Roman Kiss' ws-eventing article. He talks about the various ws-eventing delivery modes but at first glance the demo only seems to support "push mode". It seems to me that in nearly all cases an intranet based pub-sub implementation would benefit from "trap mode" (i.e. UDP multicast). Doing this in WCF is quite daunting and there is little documentation or sample code.
Could you good folks at MS please post a WCF multicast sample somewhere, or direct me to one that is already out there. Roman, if you are listening could you modify your ws-eventing sample to include trap mode?
