Summary
The article shows how to implement receiving of notification messages from the hosting server in the Silverlight application by using Eneter.Messaging.Framework.
Basically there are two approaches if you need to implement the communication scenario where the Silverlight client needs to be notified about some events on the server:
Polling
The Silverlight client regularly initiates the HTTP connection and asks the server for messages. The server then responses messages intended for the client or returns an empty response if messages are not available (that can be the majority of requests).
The advantage of the polling is that it does not block resources. (The problem is that browsers typically limit the number of concurrent HTTP connections per server to 2 - 8. The polling needs this connection only for short time.)
The disadvantage of the polling is that it can cause a lot of useless communication (in case the majority of requests return the empty response).
Pushing
The Silverlight client initiates the HTTP connection. The server receives the request but does not answer until messages for the client are not available - the connection stays open (that can be a long time). When the server answers, the client processes notifications and initiates the HTTP connection again.
The advantage of the pushing is that there is not a useless communication.
The disadvantage of the pushing is that it consumes the HTTP connection. And because browsers typically limit the number of concurrent HTTP connections per server to 2 - 8, it can happen that connections are occupied and the client application is blocked.
If you prefer to get notification messages based on the pushing, you can choose WCF. The server can implement the service and the Silverlight client can get notification messages via some callback interface.
If you prefer to get notification messages based on the polling, you do not have many possibilities. Probably you would need to implement the communication yourself by using .NET functionality for HTTP. (The client regularly polls and recognizes messages and the server constantly collects messages and responses them to the client on demand. This can easily become quite a complex implementation.)
Read more: Codeproject