Hi Matt,
answers inline. Wix setup is coming along nicely, maybe I can even finish it before Sunday, when my two week holiday starts J Cheers, 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? [David] LINQ and all the nice things associated with C# 3.0, but the CLR and base library seems pretty unchanged. 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. [David] The problem is that a) when you are on a IPv4 net it will use Teredo and b) if you are behind a firewall it does something I completely don't understand. Teredo sometimes work, but it does rely on MS servers. Even if all that would work, I just had many, many occasions where things would not even work on a local subnet, which is really ridiculous. Probably we will have to wait until MS uses this stuff seriously in one of its own products and then is forced to make this just work out of the box. 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? [David] Well, actually it has nothing to do with BizTalk, the server. It is a new channel for WCF that works in combination with a server run by MS. It essentially promises true firewall/NAT traversal capability. The channel tries to establish a direct connection with another node, but if that doesn't work, it will use the MS server to store-and-forward messages. Essentially this should allow sending messages always, regardless of network topology. My test was very simple: I decorated the interface with the appropriate WCF attributes and added some service hosting code, and it worked. The first step here would be to migrate to WCF, than using this could actually be a configuration setting. 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. [David] My main struggle right now is with dedicated mode. I don't really like the architecture, that the manager calls into the executors. I think it leads to a very difficult threading situation, makes error recovery very difficult, in particular when connections were dropped intermediately, but most of all, I don't really see any benefit from it. Why not just let every connector get a thread when it is idle, run it, get the next one? What exactly does dedicated mode give us, other than really blowing up the possible number of states the grid can be in? ------------------------------------------------------------------------- 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
