Events and Delegates with .NET Framework Remoting
Although you can use events and delegates with .NET Framework remoting, there are two main issues that must be addressed to use them successfully. In particular, you should use them only in those situations in which authentication is used over an.
Remoting delegates create a security problem that must be addressed. If a client passes a delegate to a server (most commonly done when a client attaches an event handler to a remote event), the attached delegate might refer to an unauthorized method that has the same signature as the method the service intended. Because the unintended and intended method signatures match, the service can invoke the unintended method, even if the method is static (and therefore cannot be called on the remote client).
To alleviate this situation, the server should define delegates with custom parameter types and the assembly that contains those types should have a strong name. Furthermore, you should always authenticate (if not encrypt) such communications. Never allow a type on the server to be deserialized if you are not certain that it is the type that is intended.
Given the security issues with delegates, using events is not recommended. Instead, define a client callback service that publishes methods that the service can call when it must communicate with the client. If you decide to use remoted events with an authenticated IpcChannel (and have declared delegates as described earlier), you should have the methods of your client event handler be one-way calls. The reason is that when raising events, the server invokes the delegates in the event invocation list. The eventing system blocks on that invocation until the client returns or times out. Clients that are not listening, therefore, dramatically reduce the throughput of simple events unless the event handler is a one-way method.