Hi David,
> I do use .net 3.5 Beta, and it is nice. Nevertheless, I think we should > wait > migrating to it until it is released, which should be this year in any > case. > And that for a simple reason: Once migrated you keep out anyone from > development who doesn't want to install beta, and I don't think that would > be appropriate. This is true. I'd forgotten that 3.5 is still beta. But WCF, WF and friends are part of .Net 3.0 which is released. The only (main) thing that 3.5 provides is managed wrappers for the unmanaged peerchannel stuff. Or is there more? I had a long look at the whole peer2peer technology stack from MS lately. In > theory it looks very, very nice. In particular, if you look at the data > store and the distributed record storing capability, it all sounds awesome > (although there aren't any .Net wrappers for that stuff, not even in 3.5). > But in practice, at least for my setup, which is VERY standard, > connectivity > is awful. It just hardly ever works. And if you look at the p2p blog at > msdn, you will find pages of pages of pages of "debug" steps, on how to > find > out why things don't work. Quite frankly, the whole technology to me seems > just too brittle to work with... Very interesting. I've only played around with the latest WCF samples. There is one in there that is a (very simple) p2p chat application -- you set up a server to accept new connections, then a client will connect and send a message (which gets sent to everything that is connected to the server). I understand what you're saying with the whole p2p stuff not being reliable. I'm no expert on IPv6 and everything, but it does seem extremely hard to troubleshoot. The one very cool part about the sample chat application is that their peer resolver server is run locally using a custom peer resolver service. So it doesn't rely on the Microsoft-provided peer resolution service, which greatly increases its reliability. One of the things that has been discussed in the Alchemi dev lists (mainly by Jonathan) is manager redundancy and how to handle failures in the manager. One way to do things would be to have multiple managers (or even let all executors be able to serve in a manager capacity and self-elect a new manager). Having a peer-to-peer channel for these kinds of messages would be the ideal way to do things. However, the multicast style of messaging is highly inefficient when it comes to how Alchemi grid threads will get distributed -- we still need to have unicast connections availalbe from each executor to the manager. If we would go the p2p route, it would be a hybrid system -- a p2p message channel for grid-wide administrative messages as well as individual thread connections between the manager and executors as Alchemi has now. Another very promising idea are Biztalk services. I actually had a > experimental version of Alchemi running that used it for communication, > and > it worked wonderful :) Oh really? I would be extremely interested in hearing how you did this. I am completely unfamiliar with BizTalk and the options that it provides. What benefits does it have over the current .NET Remoting architecture? If I find time I'll write up a longer email on how I would go forward with > Alchemi, I have thought a lot about it lately. I am a great fan in > incremental improvements and am quite optimistic that we might be able to > do > some significant improvements without starting from scratch. Excellent :) I would love to hear your thoughts about how Alchemi could/should proceed. -Matt ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Alchemi-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/alchemi-developers
