Is there a way to send a message to all connected clients except the client that is sending the message.
In 2014 you can select clients with Hubs.
The Others property publishes to all clients except the calling client.
Clients.Others.addContosoChatMessageToPage(name, message);
Not yet, the only thing you can do today is filter on the client side.
Related
How does Rebus ensure that a requester gets the response destined for the requester from the server?
The context is a setup with multiple clients, one backend server and two azure servicebus queues one for the client side and one for the server side. One client's response must not be received by another client.
My concern is that Rebus doesn't support sessions on azure service bus.
How does Rebus ensure that a requester gets the response destined for the requester from the server?
Rebus replies back to the queue specified with the rbs2-return-address header in the request, so if you have multiple instances consuming messages from that queue, then the reply will likely not be received by the original sender.
That's pretty much how it works, so it's important that all Rebus instances that consume messages from the same queue have the same capabilities. This implies that e.g. keeping in-mem, non-distributed state in a process that may receive replies from requests sent by other Rebus instance is a no-go.
If you describe the problem you're trying to solve, then maybe I can give you some inspiration on how to solve it.
In our app, we're using socket.io to get realtime notification.
Before connecting to the socket, we first get all of our previous notifications with a http request and then connect with the socket.
The problem was then what happen if a notification is created in the time between the end of the http answer and the connection to the socket.
But in fact, even if we connect the socket before get all of our notifications. If we don't have any possibility to get the status of the http answers, we can't know if it possiblity contains a notification received in the socket, example with our socket to get the number of notifications.
--> connecting to the socket
--> http get notifications number
<-- new notification emit in socket
<-- http answer of the notification number
How do you know if the http answer contains the new notification ?
is there a name for this "paradox" ?
Maybe we don't get it right and should use a different pattern ?
The only way I know of to solve a race condition like this is to have some identifying tag in each notification. The most common one is a tag number that increases with each notification or a time/date stamp (but you may want to make sure you don't get dups with the same time/date stamp).
Then, you can connect with socket.io and it will send you a message with the current last tag number. You can then do an http request or a socket.io message (either one will work) that asks for all messages from the last tag number and earlier (a type of query). Then, you know that you will get all the messages reliably.
So, the sequence of events would be this:
Connect on socket.io
Server sends you over socket.io the last timestamp used
You send message to the server asking for all messages from last timestamp and earlier
Server sends you all messages from last timestamp and earlier
Server sends client any new messages as they are created
It's possible to combine steps 2-4 so the server automatically sends you all earlier messages as soon as you connect, but you have to make sure this doesn't happen on an auto-reconnect when the existing web page already has all those messages. If you wanted to implement that auto-send behavior, you could use a query parameter on the socket.io connect that tells the server you want it to send you messages that arrived before your connection.
I'm trying to get a deep understand how works the Push API communication between the client and the RabbitMQ server.
As I know - but correct me in case - the client open a TCP connenction to the broker (RabbitMQ) and keep this connenction alive until the client decision to close it. But during this connection the client can get messages immediately.
My question is, during this connection, do the client monitor the Broker to ask him for messages, or when the Broker forward a message to the Queue, where the client subscribed, just take that connencion and push the data to the client?
first case: client monitor the broker for messages
last case: client don't need to monitor the broker, broker just push the data
or other?
There are two options to receive messages
The client registers a consumer callback (basicConsume) on the channel; the broker then "pushes" messages to the consumer.
The client sends the broker a basicGet and receives one message (if present).
The first use case is the most common.
Since you tagged the question with spring-amqp I assume you are interested in Spring. For the first case, Spring AMQP has a listener container (and #RabbitListener annotation); for the second case, one of the RabbitTemplate receive operations can be used.
I suggest you look at the tutorials to get a basic understanding. They cover several languages including pure java and Spring AMQP.
You can also look at the Spring AMQP Reference Manual.
Is it possible to expose a SOAP endpoint via BizTalk that calls another SOAP service without using orchestrations but just maps?
The current solution where orchestrations are being used is very slow (orchestration overhead is greater than 1,5 seconds) and performance gets even worse when it comes to high concurrency. I require a solution for low latency.
While not 100% sure for a SOAP endpoint, I have done this for WCF-BasicHttp, but cannot think of a reason why it would not be possible for SOAP. Various properties get promoted to the message context that would allow you to route a message to a send port, like the SOAP action, the receive port name, etc. Configuring a send port to subscribe to the relevant messages should be trivial. The mapping from the inbound-request to the outbound-request can happen on either the receive port or the send port.
In the case of using a solicit-response send port, the response message coming back would automatically be subscribed to by the originating receive port, assuming it is also two-way. Again, the mapping from the inbound-response to the outbound-response can happen on either the send port or the receive port.
If I send a messag using SignalR, is it possible that the client does not receive the message? How can you verify if any errors apeared in the communication? Iam thinking of sending a message back to server after the server notification was sent, but is there any better way?
Yes, it's possible that the client doesn't receive the message. SignalR keeps messages in memory for 30 seconds (by default, you can tweak that or use a persistent message bus), so if the client isn't connected for whatever reason and this timeout passes the client will miss the message. Note that if he reconnects within this period he receives all messages he hasn't got yet, including those that were sent when he was disconnected.
I don't know if SignalR provides a way of telling you when a broadcast failed, so it might be safer to just send an acknowledgement back to the server.
As long as the client is connected, it will get the messages. You can subscribe to connection state changes in client side code. In server side code you can implement IConnected and IDisconnect interfaces to handle the Connect, Disconnect, and Reconnect events.