all groups > dotnet remoting > june 2004 >
You're in the

dotnet remoting

group:

An alternative to events?


An alternative to events? le_khan NO[at]SPAM yahoo.fr
6/29/2004 6:35:56 AM
dotnet remoting: Hi NG

In one of his numerous articles, Ingo Rammer advise the .net remoting
developpers not to use events for networked application.
I'm a newbie in programming and actually, I do use events in my .net
remoting application...since I haven't yet found other ways to do what
I want.

Here is the actual scenario :
When changes are made on the remote object (Singleton SAO) by a
client, this client send a notification event to the server
So that the server will make some computations and notify all the
clients of the changes by events
The clients will thus refresh the display

How could I implement this without using events?

thank you
Re: An alternative to events? Allen Anderson
6/29/2004 7:53:07 AM
which article are you refering to on Ingo's site? If memory serves me
correctly his position wasn't specifically against events as much as
it was against anything but singlecall objects (which you can't run
events from for obvious reasons).

Personally I find nothing wrong with using events (although you take
the performance hit by losing the ability to cluster as well) as long
as you are careful to call the events manually instead relying on the
event mechanism (which can hang for many seconds).

Allen Anderson
http://www.glacialcomponents.com
mailto: allen@put my website base here.com

[quoted text, click to view]
Re: An alternative to events? k a
6/29/2004 8:33:06 AM
Thanks for your answers guys!

Using events is for sure the easiest way to do this!

Considering Ingo's recommandations
(http://www.thinktecture.com/Resources/RemotingFAQ/RemotingUseCases.html
), I was wondering whether it is proper to use events for this purpose.
Now, I'm a bit more confident :)

But, I'll try the threading solution too.

ka


*** Sent via Devdex http://www.devdex.com ***
Re: An alternative to events? Sunny
6/29/2004 9:16:54 AM
Hi,

the idea is to rethink your solution and see if you can avoid events. If
you can not, the ok, go with it. In your situation you have 2 options:

1. events - this is easiest and natural way. Just be sure to implement
some kind of your own broadcasting machine, because you can have
problems with native events support if some of the clients fails. Then
all other clients will not receive the event as well. You cant read this
article for ideas:
http://www.genuinechannels.com/Content.aspx?id=27&type=1

2. Create a separate thread at the client and at regular intervals pull
from the server the new state. If you change the state of the server
really often, then this will not create a big overload. But this is
unreasonable if you lets say change server state every 1/2 hour, but
pull for new state every 30 secs.

Sunny


In article <8f1b5e2a.0406290535.cef1bc6@posting.google.com>,
le_khan@yahoo.fr says...
[quoted text, click to view]
Re: An alternative to events? Allen Anderson
7/5/2004 9:13:31 PM
np, glad to help.

[quoted text, click to view]
AddThis Social Bookmark Button