From the docs it is clear that message delivery is not guaranteed by django-channels. I want to implement a way in my chat app so that there is a guarantee that messages are delivered to the client.
I am using redis, if that matter. When I say messages I don't mean chat text messages. I haven't implemented that part and don't need that for now. I just have video call feature. What gets lost sometimes is when users join the room the room members list doesn't reach them. So I want to do something like:
Client connects.
Servers creates a record of the event in step 3 below.
Server sends the list of room members event to the client.
Client process and acknowledges the list.
Server on receiving the acknowledgment from the client marks the list sent event as SUCCESS or something.
My questions are.
Is this approach good?
And should I use a new model to store the message events so that server can know which messages to sent and which have been already sent successfully or is there anyway to do it in redis db?
I am new to this so I maybe overlooking something that you as experienced guys know of. Please guide me with your precious inputs.
Thanks
Related
we are looking at socket io implementation for a chat application.
Finding acknowledgement support to handle missing messages while broadcast we are looking at acknowledgement support.
as per documentation socket io does not have support for callbacks in broadcast / rooms.
e.g. in "Room 1" we send broadcast message to all sockets within that room. how we check without call back that some users/sockets missed the message. and how we will handle that in system.
below code does not work.
io.sockets.in(data.room).emit('message', data, function(responseData){
console.log(responseData);
});
according to below issue
https://github.com/socketio/socket.io-redis/issues/30
Callbacks are not supported when broadcasting.
what are the other methods to handle this scenario.
In order to solve your problem, the messages for a room need to be persisted somewhere, and then re-sent to individual clients as needed.
The most obvious place to store messages is server-side, in a datastore (e.g. Redis). Store each conversation effectively as a list of events, appending new events as they happen.
A simple scheme works as follows:
Each broadcast message has a UUID attached to it. When the server handles a new message, it appends the message to the list for that 'room'.
When a client connects/re-connects, it sends a message (e.g. 'LAST_MESSAGE_RECEIVED') indicating the UUID of the last message it received.
When the server receives one of these 'LAST_MESSAGE_RECEIVED' messages, it checks if that is the latest message for the room, and if not, it emits a message just to that individual socket with an array of the missed messages. The client is now back up-to-date.
Alternative: if you don't need to keep a history after a conversation ends, you could be clever and use the fact that other clients are already storing the messages, and ask the clients to re-send messages in a peer-to-peer kind of way. This avoids you needing to have your own server-side datastore.
I have a PUB server. How can it tell what filters are subscribed to, so the server knows what data it has to create?The server doesn't need to create data once no SUB clients are interested in.
Say the set of possible filters is huge ( or infinite ), but subscribers at any given time are just subscribed to a few of them.
Example: Say SUB clients are only subscribed to a weather feed data for a few area codes in New York and Paris. Then the PUB server shouldn't have to create weather data for every other area code in every other city in the world, just to throw it all away again.
How do you find out all the subscribed to filters in a PUB server?
If there is no easy way, how do I solve this in another way?
I'll answer my own question here in case its of use to anyone else.
The requirements where:
The client should be able to ask the server what ids (topics) are available for subscription.
The client should chooses the id's it is interested in and tell the server about it.
The server should created data for all subscribed too id's and send that data to clients.
The client and server should not block/hang if either one goes away.
Implementation:
Step 1. Is two way traffic, and is done with REQ/REP sockets.
Step 2. Is one way traffic from one client to one server, and is done by PUSH/PULL sockets.
Step 3. Is one way traffic from one server to many clients, and is done by PUB/SUB sockets.
Step 4. The receives can block either the server or client if the other one is not there. Therefore I followed the "lazy pirate pattern" of checking if there is anything to receive in the queue, before I try and receive. (If there is nothing in the queue I'll check again on the next loop of the program etc).
Step 4+. Clients can die without unsubscribing, and the server wont know about it, It will continue to publish data for those ids. A solution is for the client to resends the subscription information (with a timestamp) every so often to the server. This works as a heartbeat for the ids the client has subscribed too. If the client dies without unsubscribing, the server notices that some subscription ids have not been refreshed in a while (the timestamp). The server removes those ids.
This solution seems to work fine. It was a lot of low level work though. It would be nice if zeromq was a bit higher level, and had some common and reliable architectures/frameworks ready to use out of the box.
Hypothetical: I want to send a single text message to all Verizon phones programmatically. I have multiple email gateways to use (obtained from the all-reliable wikipedia):
number#vtext.com
number#vzwpix.com
number#message.alltel.com
number#text.wireless.alltel.com
number#mms.alltel.net
I don't think that I'm guaranteed that any one of these will work and/or will still be in service (am I?) and I would not like to have to come back and change anything in the code at a later date.
Is there any way that I can make sure that I only send one text message to a given phone number when there are 5 possible gateways?
The only way way (that I know of) to ensure you only deliver one message to the recipient is to try each gateway sequentially until a message sends successfully, like some of the comments mentioned.
However, I've been sending a decent volume (>1500) of messages using #vtext.com lately and haven't noticed any bounces or downtime during sending. I have no way of knowing if every single message was delivered, but none of my test numbers have dropped a message yet. Most US carriers seem to have decent reliability on their gateways these days.
Just remember that SMS is still considered a best-effort service by most carriers. Even if you get your message to their servers successfully, there's no guarantee that the message will make it to its destination.
I have a simple messaging system on my site. I would like to implement limits on messages. For basic users, users can have store a maximum of 250 messages in their inbox and supporters can store a maximum of 3000 messages.
My question is about the UI aspects.
If a basic user already has 250 messages:
would you block another user from being able to send them a message until they have deleted some messages?
Or would you put the new message in a queue and not show it until a user has deleted some messages?
Would you tell them they have new messages waiting but they can't read them until they've deleted some messages?
What would be your approach?
I would suggest an automatic delete that the oldest messages are automatically removed when newer messages arrive.
Edit: See comment below.
Also, besides this method, you could make a way to save some messages or make them favorite to prevent auto-deleting them.
I have a basic question about, the JMS architecture. A typical arrangement can be point-to-point, were message from customers are interleaved. that means that concurrent communication is not supported right?
now in publish and subscribe we can have lots of customers registered in one or more topics, and each time a message is sent all the registered customers receive the message right?
(i guess it is done by using multicast right?)
if i wanted to implement JMS for sending queries to a database, and receive responses from the database, then the publish and subscribe method should be used right? I can't do it with point - to - point, if i have multiple client right?
You can do it with point to point, you just probably wouldn't want to.
For database interactions, you probably want a data grid, not a message queue - and you can use temporary queues if you really are desperate to fit JMS into the architecture.
I guess I have a question for you: what exactly are you trying to accomplish?