I'm making an application in which three users get into a session and send each other UDP data (Peer to Peer). How can I detect if one of the users has disconnected from the session?
Because UDP is not connection based, the only way to tell if a user has disconnected is to check if you are no longer receiving responses or messages from them.
One strategy is to have users send 'heartbeat' messages periodically and track if a user has missed the last X number of heartbeats in a row, and at that point assume they are disconnected. These messages don't need to contain any information, just receiving them is what's important.
You should also have users send a "disconnection message" when they disconnect, but do not rely solely on this, as the user may crash or the message may otherwise get lost and never be received.
Related
I am using SignalR in my application to send messages to different users in a group.
We have the capability that messages can be added/edited or deleted and the same action is sent to all the users in that group via SignalR hub.
All that is working fine.
The issues is one could miss other people actions (message add/edit/delete) which happened during the time when his connection was lost/ internet disconnected or his laptop/machine was off.
After getting connection back or opening the laptop again that user must receive all those missed messages, missed actions which occurred during the time he was offline.
We are storing all clients (client id) of all users in database.
Can anyone give the pointers how to do that?
One solution can be to poll last message id (which has come to ui) to server check if any new message is there but that won't serve the purpose because message could have been edited/deleted at server from other user.
I have already gone through following links
Can SignalR handle missed messages?
Can a SignalR message loss be detected server side?
How to do guaranteed message delivery with SignalR?
Signalr client to retrieve missed messages on reconnect
https://github.com/JabbR/JabbR/issues/699
but none of them is covering the aspect for the entire history which happened during the time user was offline.
For example if you are disconnected in Skype and comes back say after few hrs it pulls all the history of all actions (message added/edited/deleted) that occurred during that time and update it to end user
Since SignalR doesn't povide any guarantees of message delivery - one should solve this by himself.
There are several approaches:
The first is to use message queues (ex: RabbitMQ).
This is the most efficient way to guarantee that message is delivered to client.
But in your case you'll need to combine message queueng with pub/sub way of communication. That can be tricky.
The second way is described in the answer to one of SO posts, that you referenced: Can SignalR handle missed messages?.
Don't send data over signalr, only notifications; then get the data update from the server.
That is my favourite way of client-server notification/update scheme. And I'd choose it in your case.
One solution can be to poll last message id (which has come to ui) to server check if any new message is there but that won't serve the purpose because message could have been edited/deleted at server from other user.
To overcome this you can poll not the last message, but history of actions made in conversation (add/update/delete message actions) since last updated and apply it on the client side.
I have two machines A and B,A is used for sending message while B is used for receiving message.
Now,i power off B so the message sent out by A is store in outgoing queue.My question is:
1.As a developer,how can i know the message has reach B?(when B is not available,the application that send the message exit as usual,no exceptions were thrown)
2.How to resend the message in outgoing queue when B is start?
Theoretically speaking, MSMQ is a technology for sending messages into an asynchronous manner and more importantly, into a disconnected fashion (the receiver maybe is NOT connected to the system yet).
The sender, if he doesn't receive a MessageQueueException (https://msdn.microsoft.com/en-us/library/system.messaging.messagequeueexception(v=vs.110).aspx) then he can consider that the message is sent successfully. If you really want to see in "real time" whether B received a message from A or not, you should rely on other communication technologies (direct TCP connection or something that wraps a TCP communication channel, such as .NET Remoting or WCF).
As I said, B maybe is not online yet or has been shut down for no matter what reasons ... So for your second question, I can tell you that you don't have any problems because whenever B restarts, it should call again "Receive" on your queue (to dequeue any message sent by A).
Read the following link: http://www.primaryobjects.com/2007/08/13/using-the-microsoft-message-queue-msmq-and-c-asp-net/ I think it is helpfull.
"As a developer, how can I know the message has reach B?"
Journaling is what you need.
Writing in MSMQ's personal journal
"How to resend the message in outgoing queue when B is start?"
Delivery of messages in outgoing queues is looked after by MSMQ. You don't need to resend. Just wait for the destination to come online.
I currently have a system in which the apps ping each other to check they're still alive. I have 1 client, which sends requests, 1 router which distributes them and 2 workers which do the work and return the results.
If a worker dies, the router works it out and only sends to the other. This gives me time to see whats gone wrong and act accordingly. If the router dies, then the client knows about it. What I would like to know however is if my client works out that the router's died, (which it can do), then it takes any messages being queued up and simply sends them back.
It's a chat app, so somebody will send a message, this will go to the client dealer port. The dealer will suddenly go "waaah the router's dead!" and send the message back along with an error to say the system is currently down. This way if catastrophy hits, users will know that the system is down and stop sending messages until it comes back up.
Is there a way to do this? Am I right in saying that the high water mark knows internally how many messages have currently not been sent, and maybe I could use some function to get all the queued messages back off zero mq?
Many thanks
Nope, you'll have to handle it in your application. You'll need to keep a copy of the message, if ZMQ pukes and is unable to send it, you can manage that appropriately in your application. Once you have determined it has gone through, then you can discard it.
For those who have a similar thought, I found the best solution was actually to add a timeout on the client side. Cache the last data requests on the users browser and if there hasnt been a reply within a suitable time frame, file an error report.
Failing that, the only other options I could find were to either handle the caching yourself or use a different messaging platform (rabbitmq, activemq). The memory requirements alone bothered me too much to consider these however personally.
How do you 'verify' that a message sent using MSMQ to a private local queue was actually delivered? I'm especially thinking of a scenario where the listener (a C# service in my case) is not running and therefore delivery can't be successful.
You can only guarantee that it can get to the queue without taking extra steps. To deal with the "not running receiver" scenario, you would need to code the receiver to send a message back to the server when it processes the message. The original sender would be responsible for tracking the sent messages and verifying that the client has recieved them.
That's one of the decisions you should be taking when deciding whether or not to use MSMQ as opposed to a remoting or a web service scenario. For example, we had a project used for notifying all of our retail locations when an emergency occurred (such as a product recall/food safety issue.) We needed to know immediately if the store's listener was running so we chose remoting, and when the sender received an error indicating one of the listeners was not listenting, we would need to pick up the phone and call.
Just something to keep in mind.
Edit - clarification
I was really giving out two options above.
Code the client to send a message back to the sender when it receives a message.
Use another option, such as remoting, where you can detect if the client is running and receives the message.
It's always sent to the queue.
If your service isn't running to receive it, it just sits there, waiting patiently, until someone receives it.
You know it's been sent to the queue because .Send() returns without crashing.
You can probably pull this info out using administrative queues
When you send a message you can specify the AcknowledgeType which will allow you find out (through positive or negative acknowledgement) whether the message reached the queue and/or was received from the queue. Acknowledgements are sent as messages, by MSMQ, to the AdministrativeQueue so make sure you assign that property on the Message object.
You can check the administrative queue for acknowledgements by correlation ID which is ID of the original message.
I have to maintain a single persistent socket connection to a payment gateway and use it to send financial messages and receive confirmation for the same. My application will be then used by various clients and so I need to devise a way to handle them concurrently and handle issues such as timeouts and retries etc.
Right now, my main issue is with accessing the socket... should I just lock the send and recv per message request and response or set up a queuing system and match them? I'll also be sending periodic echo messages on another thread.
Oh, and I am planning to do it in C#. I would appreciate some general advice on this issue.
You need a persistent socket to the payment gateway, ok. By that I assume you mean it must stay connected.
Then you need to create a listener socket to listen for connections from your clients. Then act as a translator between the two.
I'm not sure I understand what you mean by "lock the socket". Lock it how?
Unless the protocol for the payment gateway is intended for multiple concurrent operations, you probably don't want to send more than one request at a time. This would mean a queue of some sort, or a thread for each request using some kind of mutex or semaphore to control access. A queue is more efficient in most cases.
I did this exact thing (if I understand you correctly). I have a server that connects to some target devices over sockets and then clients hook up to the server to talk to different target systems. Is this (kind of) what you want? I have multiple clients talking to the same socket through the server.
In my server I keep a list of connected clients and a list of connected targets. When a client requests a target I add it to a matrix that is essentially a dictionary of connections because several clients can talk to one target at the same time. The server then pumps messages between clients and targets entirely asynchrounously and I use transaction IDs to keep track of the messages. So that when a target answers a request the server knows to which client to send the answer.
I'm not sure this is what you want but maybe what I did will help you a little on your way anyway. If I'm on the right track I can elaborate further.