Async Return on Sever Message to Client - c#

I have a number of clients that send objects to server1 using Post requests which in turn get sent to server2 using sockets.
Server1 Processes a post requst message from client converts to serverMessage. SeverMessage is sent asynchronously. it listens continuously for response messages that can come in any order but will have their id to identify them.
How do i send a response back to the original thread once Server1 has processed the correct MessageId

If I understood your architecture correctly, You have a gateway or something like a service locator between your client and your business service provider and also the communication between these two servers is async. So you want to send back the procced request from the business service provider to the middle server. If this is your architecture I can recommend two solutions may be been useful:
1. Keep the state in business service provider:
keep the result of any request in some safe place (DB or Memory based on your business) in business service provider and implement a service to accept messageId and send back the result, Then considering to a meaningful period of time in your service broker (server1) you can ask for the result
2. Make a full duplex communication:
You can also provide a service endpoint in server1 and once any process finished in server2 it can send the result for server1 through the endpoint

Related

msmq message received more than one time in wcf service

I have a wcf service with msmq binding. WCF service process messages receives from MSMQ queue. I am using transactions in client and wcf both. I am having a issue that even after successful processing of the queue message, the message is not deleting from queue and same messages is again received by the wcf service. So one single message is received more then once and processed.
Please help me why the message is coming more then one time even after successful processing. Is there any settings that I need to done at service side?

Notification Service in C#

I am going to design a notification service which is supposed to do the following:
Clients call notification service at startup with initial data (client ip, client id).
The server saves clients in connected clients list using their IPs.
If one client needs to notify (send message to) other clients, it calls a method on the notification service to publish this message to other clients using their IPs.
On client shutdown, the service removes this client from connected clients list.
My Question is:
1- Is this an applicable design for such a notification service?
2- I know that connections between service and client can be implemented using WCF callbacks, Microsoft Message Queue and Sockets. Is there any other technology / method that can be used in c#?
Note:
Now, clients are .net c# applications, but in the future clients may contain mobile applications, so i need a method that is platform independent.
Thank you

WCF - NetMsmqBinding vs NetTcpBinding

I was going through this article http://weblogs.asp.net/spano/archive/2007/10/02/choosing-the-right-wcf-binding.aspx to choose Binding options.
where i got an unusual doubt of what is mean by
offline or disconnected interaction, choose the NetMsmqBinding
Does that mean the even if service is not running still client using the service ?
Can you share some real time example ?
The 2 bindings are radically different.
NetTcpBinding can be thought of as an MS proprietary format (usually binary) similar in concept to RPC (e.g. can be used to replace .NET Remoting). It is synchronous, i.e. both client and server must be online at the same time, and the client receives a response (almost) immediately.
MSMQ is a Message Oriented Middleware solution by Microsoft, which revolves around asynchronous queues - e.g. if the destination server is offline when the client sends a message, the message will be queued on the client until the server comes back online. Each queue is one way only, although bidirectional communication can be achieved via a second queue back from server to client. Sending WCF MSMQ messages requires that the MSMQ Service be installed on the client. Messages on the queue can have a delivery 'timeout' else will be placed on an applicable dead letter queue.
Real world examples:
I would use NetTcpBinding with binary serialization for high performance, synchronous communication needs between a Microsoft WCF client and server, e.g. uploading files, media etc where Xml would not be useful (otherwise, I would use wsHttpBinding for synchronous Xml / SOAP messaging)
I would use MSMQBinding with DTC enabled to ensure reliable messaging between 2 or more systems (e.g. financial), with at least one of the endpoints being in .Net, and a 'compatable' server (not necessarily WCF, e.g. BizTalk, or other EAI hubs or ESB buses which have adapters for MSMQ, e.g. Bridges exist between MSMQ and MQSeries). Messages would typically be in an Xml format.
TL;DR
Does that mean the even if service is not running still client using the service
Yes. If MSMQ is running locally, the client will get an immediate return successful response (indicating that the message has been queued). This does not however mean that the message has been successfully received by the server.

NetTcpBinding: send and receive simultaneously

Consider a service that uses NetTcpBinding in duplex mode: the instance of the service receives messages, while the callback is used to send messages in the opposite direction. Can you receive and send data simultaneously? In other words: while the service instance is receiving some data, at the same time can you send data via the callback for the client (the client of the service instance)?
Raw TCP can send and receive at the same time. I wouldn't expect the NetTCPBinding to be any different. TCP is a bi-directional connection and the source and destination addresses distinguish between the direction as well as sequence numbers in the TCP packets.
Try it by writing two threads, a sender and a receiver and perform the respective operations in both at the same time.

WCF duplex callbacks, how do I send a message to all clients?

I am using WCF with duplex netTcpBinding and I want to send a message to all users connected currently to my service. I thought I could just create a callback contract and it would send a message to all the clients but it seems I am mistaken, and there isn't a single server/service, each client gets its own service?
I have service with the name 'Server'. Here is how I access the server from the client -
ServerClient client = new ServerClient();
string result = client.SendMessage(messageTextBox.Text);
client.Close();
I thought the 'Server' was a single object that handled all calls by my clients but then I've started a thread in the Server constructor and I found out that multiple threads get started because every time a client calls the Server, a new Server object is created.
So it seems each client has it's own service/server.
With that in mind how do I send a message to all my clients from the server?
I thought the standard practise for accessing the server from the client was to get a proxy object, call the service functions, and then Close the proxy object like in the code above...but if I close the proxy object doesn't it mean I have closed the connection between client and server and now the server won't be able to make duplex callbacks to the client?
1) If you want all clients to share the same server, you need to make your service a singleton. Add this attribute to the class implementing your service (not the interface):
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)]
That said, I suspect that what you really want is a synchronized, static (thread-shared) instance of a List<ServerClient>. Then you would iterate over that to send a message to each client. With that design, you wouldn't need a singleton server (just some good thread safety around the list).
2) If the clients close their server proxies, the server will not be able to send them any messages. You need to keep the proxy open and stash them somewhere in the client. This design will of course significantly limit scalability.
By default each client will get its own instance of the service. You can however make your service a singleton (which will than process requests from all client).
You may also want to skim through this Instance management article

Categories