I have set up a chat server with Ejabberd, It is working fine. Messages are getting sent from one user to another user. Problem is that when the receiving user is offline, Sender messages should get stored and get delivered to receiver when he comes back to online. But offline messages are not getting delivered. I have not changed anything in configuration file because it looks already configured for the offline storage and offline message delivery. Do I need to make any other changes apart from the below lines?
ejabberd.cfg:
{access, max_user_offline_messages, [{5000, admin}, {100, all}]}.
{mod_offline, [{access_max_user_messages, max_user_offline_messages}]}
Please update your ejabberd from 2.1.10 to 16.10, as you using the older version certain func. may not work as expected.
Related
I have a very simple alert mechanism to alert drivers "in-the-field" when a new pickup has been assigned to them. I have had an instance twice where a driver has responded with a STOP and became un-subscribed. Once discovered we acquired the proper opt-in documentation from them. Is there any way to re-subscribe a user that opted out and changed their mind on receiving the messaging. i.e. they issued the STOP to the incorrect SMS. And have deleted the original message to START. Or do I need to code something for them to opt back in
My SendGrid provides a method to remove suppression from email but am not finding anything like that here in Twilio.
They need to send a START to the number they previously opted out of, this is currently a requirement. You will also get an error when trying to send messages to them, to alert you they opted out.
Error 21610 - Attempt to send to unsubscribed recipient
I am facing an issue with the presence status, following the documentation and XMPPframework example code. I have written a chat application.
Problem : When the user 1 & 2 are online I get the status successfully and they can chat with each other. However when the user 2 goes physically offline via (Wifi OFF / 3G Off) User 1 is not getting the offline status from XMPP and hence what ever messages are sent from that instant of time are lost when the user 2 comes online.
It seems since the user 2 is not notified or stored as offline in XMPP and hence its not storing the offline messages to push back to user 2 when it comes online.
I have tried to resolve this by explicitly writing a [goOffline] call to XMPP, however the call is shown in 'SEND log' for 'user 2' but not received in 'RECV log' in user 1 from XMPP, due to which the message are lost in between.
Also tried with other sources replies.
Set status for presence available and send XMPP
priority changed with values non-negative
XMPPArchiving work but this is not what I wanted.
Server side Mod_zero push enables but get only first message push notification sometimes.
Setting limit on ejabberd.cfg file for users and offline message limit.
request for offline message pull.
Can anyone help me with this?
This is very typical situation where client losses network but server can't detect that it is offline.
To detect status of each client, server need to send PING packets to every client and wait for response.
If client responds then fine otherwise server will mark that client as offline and every other online client will be informed automatically.
Here is PING Module implementation for ejabberd XMPP Server (hope you are using ejabberd server):
mod_ping:
send_pings: true
ping_interval: 10
timeout_action: kill
ping_ack_timeout: 10
This has to be written in ejabberd.yml configuration file.
At client side also we need to enable ping module to respond to server pings as:
private var xmppPing: XMPPPing?
xmppPing = XMPPPing()
xmppPing!.activate(xmppStream!)
This code has to be written while we setupStream() for iOS.
For detailed info, please go through mod_ping documentations.
Sounds like your problem is at server level. The server thinks that the user is online so it sends the message but nobody gets it. This does not really have a simple solution.
1.
The best solution would be delivery receipts. Where basically when the message is sent to your client, your client returns a confirmation of delivery receipt. If the server does not get that receipt it would resend the message every n time. Depending on your XMPP server you might find a already made solution, of not you would have to roll out your own.
2.
A possible hack would be to have your server always store and deliver last 10 messages and then at client side you discard repeated... This also depends on your server implementation. XMPP MUC and PubSub have resources along these lines.
For a long term scalable solution, you'll need to deal with this both at server and client level.
i went through this question
Lost messages over XMPP on device disconnected
but there is no answer.
When a connection is lost due to some network issue then the server is not able to recognize it and keeps on sending messages to disconnected receiver which are permanently lost.
I have a workaround in which i ping the client from server and when the client gets disconnected server is able to recognize it after 10 sec and save further messages in queue preventing them from being lost.
my question is can 100% fail save message delivery be achieved by using some other way i know psi and many other xmpp client are doing it.
on ios side i am using xmppframework
One way is to employ the Advanced Message Processing (AMP) on your server; another one is to employ the Message Delivery Receipts on your clients.
The former one requires an AMP-enabled server implementation and the initiating client has to be able to tell the server what kind of delivery status reports it wants (it wants an error to be returned if the delivery is not possible). Note that this is not bullet-proof anyway as there is a window between the moment the target client losts its connectivity with the server and the moment the TCP stack on the server's machine detects this and tells the server about it: during this window, everything sent to the client is considered by the server to be sent okay because there's no concept of message boundaries in the TCP layer and hence if the server process managed to stuff a message stanza's XML into the system buffers of its TCP connection, it considers that stanza to be sent—there's no way for it to know which bits of its stream did not get to the receiver once the TCP stack says the connection is lost.
The latter one is bullet-proof as the clients rely on explicit notifications about message reception. This does increase chattiness though. In return, no server support for this feature is required—it's implemented solely in the clients.
go with XEP-0198 and enjoy...
http://xmpp.org/extensions/xep-0198.html
For a XMPP client I'm working on, the following mechanism is used:
Add Reachability to the project, to detect quickly when the phone is having connectivity problems.
Use a modified version of XEP-0198, adding a confirmation sent by the server. So, the client sends a message, the server confirms with a receipt. Later on, the receiving user will also confirm with a receipt. For each message you send, you get two confirmations, one from the server, one from the client. This requires modifications on the server of course.
When the app is not connected to the XMPP server, messages are queued.
When the app is logged in again to the XMPP server, the app takes all messages which were not confirmed by the server and sends them again.
For this to work, you have to locally store the messages in the app with three possible states: "Not sent", "Confirmed by server", "Confirmed by user"
I have an issue delivering messages in chat when one of the users goes "offline".
When 1-on-1 chat is initialized and two users are chatting, messages are being delivered and everything works great, but when app of one of the users goes background, the other one keeps messaging. It looks like messages are being sent, saved into history and cache (I log it), but when the other users goes back online and retrieves history — these messages do not appear.
In the logs I see them coming with the delay after the app restarts:
2013-03-13 01:14:42.983 MyApp[2314:1103]
QBChat/xmppStreamDidReceiveMessage:
<message xmlns="jabber:client" id="0" type="chat" from="XXXXX-XXXX#chat.quickblox.com"
to="XXXXXX-XXXX#chat.quickblox.com">
<body>I try again</body>
<delay xmlns="urn:xmpp:delay" from="chat.quickblox.com" stamp="2013-03-13T07:58:14.455+0000">
Entire messaging process is built using code from SimpleSample chat
(Also, I do not use Push Notifications yet).
Can you, please, advise me something on this issue?
Thank you.
UPDATE: After reinstalling the app, message history with the user isn't retrieved, that means, I guess, the history I was talking about was stored in cache. Seems like I have issues in retrieving history from server. I have tried 'message.delayed = 1' in 'ChatDidReceiveMessage', but it didn't help.
You have to logout from Chat when you go to background and login again when you go to foreground.
Your messages will be received OK in this case
im stuck in a situation
SITUATION : I have a situation wherein i answer some questions and get points according to the answered questions. if my points become say 10 i win some gift using a QRCode. (there is a qr code that is generated to the user, and when the qrcode is scanned from someother device which has a scanner app or any other scanner, it gives a link to that online store. This link can be opened from any browser.) The gift is accessed from some online store by scanning the QRCode which gives a link to that online store with some unique id and when the gift is accessed/taken the server is notified that the gift is accessed/taken from that online gift store and the QRCode status is updated to invalid on the server database. Now once the server gets the notification that the gift is being accessed/taken, the server should immediately notify my iphone app that the gift is received so that i can immediately show another congratulations image or something.
POSSIBLE SOLUTION : i thought of one possible solution wherein i check upon the qrcode access status change on the server every say 60 secs and display the image accordingly. I dont know how efficient/correct this way would be though.
ISSUE : but before i refuge to the above solution, i want to know, can this notification happen from the server without my app trying to call or fetch the update from the server? I mean, my app comes into the picture only after the server sends a notification in the form of a msg or some xml or something..
Any help would be deeply appreciated.
You can open a connection to your server using CFReadStream, add the stream to your runloop and set up a callback function. Whenever the server writes data to the open connection, your callback will fire and you can then read from the stream to get the data the server sent
More info here: https://developer.apple.com/library/mac/#documentation/Networking/Conceptual/CFNetwork/CFStreamTasks/CFStreamTasks.html
You could try to check Push Notifications. But it's impossible to determine on server side if notification was received on client side or not (if you won't implement it by yourself, but you'll probably wont cover all the possible situations, like when your app is not launched and notification came).
you can try to use XMPP protocol, which is most commonly used for chats/mails, where the changes in the server is notified to the clients.
Apple Push Notification Service is meant to solve these types of situations.
Hope it helps:
Apple Docs: http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html#//apple_ref/doc/uid/TP40008194-CH100-SW9
There is a nice tutorial: http://www.raywenderlich.com/3443/apple-push-notification-services-tutorial-part-12
Video tutorial: http://www.youtube.com/watch?v=cKV5csbueHA&feature=relmfu