[Mono-dev] Remoting Server Events problem

[buhochileno at gmail.com]

Thanks Robert I'm trying to follow your code, I need more training with 
generics, so this is a good excersice to :-) ...
Some design sugestions.:
- Do you recomend to have a "remoting server version" of the class that 
you want to use with remoting?
- also a "client remoting version" of the real class?, I mention this, 
becouse in my case if is posible I want  to expose the events, in the 
client side, like traditional cli events, so if I have a remoting client 
version of the class I can deal with the "remoting events" technic that 
you show me and expose the same events but in a traditional cli way, 
that make sense :-S ?

thanks.

Mauricio

Robert Jordan wrote:
> Hi,
>
> buhochileno at gmail.com wrote:
>> Thanks Robert, I very confuse with this, becouse I read a lote of 
>> diferent approach (event broadcast engines, shared objects, etc) to 
>> do this, but most of them don't work :-S ,  I wondore if you have a 
>> simple working example of the correct way to do this?
>
>
> Events only make sense in local cross appdomain contexts.
> Anything else is a world of pain. See
> http://www.thinktecture.com/resourcearchive/net-remoting-faq/remotingusecases 
>
>
> The attached sample is still using events on the server side but
> it requires that clients implement a certain interface that
> was declared in the shared assembly.
>
> The server is using a special "AsyncEvent" that doesn't have the
> drawbacks of a simple CLI event:
>
> - the clients are notified sequentially. This doesn't scale
>
> - if a client doesn't respond, the next clients won't be called
>   back anymore. This is far from being reliable.
>
> AsyncEvent is calling the clients in parallel and it also disconnects
> failing clients. This is still not optimal because it doesn't scale
> at large: Imagine you have 1000 connected clients ...
>
> Robert
>
>>
>> in advance, thank you very much.
>>
>> Mauricio
>>
>> Robert Jordan wrote:
>>> buhochileno at gmail.com wrote:
>>>  
>>>> Hi:
>>>>
>>>> I know that is very possible that this is a basic remoting 
>>>> question, but I read some info about the native .NET approach used 
>>>> with remoting and I think that my code is supose it to work:
>>>>
>>>> I write a class with a method to trigger some event (this is the 
>>>> object resgitered by the remoting server):
>>>> [Serializable]
>>>> public class Camera: MarshalByRefObject
>>>> ...
>>>>    public void SetZoom(int amount)
>>>>    {...//zoom code
>>>>        SomeDelegate h = this.SomeEvent; //some test event triger, 
>>>> the SomeDelegate is public...
>>>>        if ((h != null) && (SomeEvent != null))
>>>>                h (this, new EventArgs());
>>>>        else
>>>>                Console.WriteLine("null then?"); //allways is null
>>>>       }
>>>> ...On the client side I use a special "RemoteCamera", this class 
>>>> deal with all the remoting stuff related to get the object from the 
>>>> server...something like:
>>>> [Serializable]
>>>> public class RemoteCamera: MarshalByRefObject
>>>>        public RemoteOrbitKit()
>>>>        { .../channel registration, etc...
>>>>             
>>>> camera(ICamerat)Activator.GetObject(typeof(ICamera),_fullObjectURLPath); 
>>>> //....
>>>>            camera.SomeEvent += new SomeDelegate(SomeMethod);
>>>>             ...
>>>>             camera.SetZoom(50); //this work, but the event is not 
>>>> triggered...
>>>>
>>>>        }
>>>>        public SomeMethod(object sender, EventArgs e)
>>>>        {
>>>>             Console.WriteLine("method called"); //This methis is 
>>>> never called becouse the Event/method asociation allways is null
>>>>        }
>>>>
>>>> Do you see what is my mistake?
>>>> sugestions?, ideas?
>>>>     
>>>
>>> 1. The server must know the type "RemoteCamera", because the delegate
>>>     is containing a reference to an instance of this class.
>>>
>>>     You can circumvent this by using a public static method as
>>>     an event handler.
>>>
>>> 2. The client must start a listener as well. This is done with
>>>     "new TcpChannel (0)" or "new HttpChannel (0)" or with a
>>>     corresponding remoting configuration setting.
>>>
>>> 3. The client must not be firewalled because it is
>>>     called back by the server.
>>>
>>> Robert
>>>
>>> _______________________________________________
>>> Mono-devel-list mailing list
>>> Mono-devel-list at lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>
>>>   
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>