Distributed Applications

Posts   
1  /  2
 
    
jeffreygg
User
Posts: 805
Joined: 26-Oct-2003
# Posted on: 29-Oct-2004 18:43:24   

Large tome written by Devildog

Let me just take a few weeks to assimilate all of this, Devildog, and I'll get back to you. simple_smile

In regards to eventing, what do you think of this article from Ingo Rammer?

http://www.thinktecture.com/Resources/RemotingFAQ/RemotingUseCases.html

From the article:

Don't use Events or Callbacks

No matter which category your application belongs to, I heavily recommend NOT to use events, callbacks or client-side sponsors for networked applications. Yes, it's possible to use them. Yes, they might work after applying one or another workaround. The real trouble is that they are not exactly stable and don't really perform that nicely.

The reason for this stability/performance drawback lies in the invocation model. First, you have to make a decision on whether to invoke events synchronously or asynchronously from the server's point of view. In the first case, your server has to wait until all clients acknowledged (and processed) the callback which increases the request time by a magnitude. If however you decide to use them asynchronously, you might run into a number of different issues - of which ThreadPool starvation is only the smallest and lost events is the more critical one.

But what if you need notification of clients? In this case, I'd either look into UDP or message queuing, depending on your needs for reliability. The use of MSMQ allows your server-side application to send messages to listening clients without having to wait for acknowledgements of reception (or even wait for processing at the client). This allows for way better turnaround times for your requests.

Jeff...

Devildog74
User
Posts: 719
Joined: 04-Feb-2004
# Posted on: 29-Oct-2004 19:05:26   

MSMQ is an option, it isnt that difficult to implement, but MSMQ needs to go on all machines, but its much more scalable than remote server invoked events. Plus youre guaranteed delivery of messages. So MSMQ is an A+ choice if the load will be high, and you need to guarantee delivery of messages.

COM+ is another really good option, because it will take care of a lot of the details for you. Loosely Coupled Events are basically the same thing as what we have been talking about with respect to having the server raise events back to the clients. Here is a decent article from microsoft of the topic: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncomser/html/compluscouple.asp.

Aside, from that, Ingo's article pretty much hit home with what weve been talking about in this entire thread. You need to know the tools out there, and choose to use the set that best fits your needs. If you dont need to go outside the firewall, dont need to use soap, wont have a high load, and are willing to possibly loose a few messages in the mix, remoting would probably be the fastest, simplest, and cheapest way to go.

Note: The code sample that I did is a slightly modified version of a sample in his "Advanced .NET Remoting in C#"

1  /  2