Send XMPP message without starting a chat - xmpp

I am basically writing a XMPP client to automatically reply to "specific" chat messages.
My setup is like this:
I have pidgin running on my machine configured to run with an account x#xyz.com.
I have my own jabber client configured to run with the same account x#xyz.com.
There could be other XMPP clients .
Here is my requirement:
I am trying to automate certain kind of messages that I receive on gtalk. So whenever I receive a specific message eg: "How are you" , my own XMPP client should reply automatically with say "fine". How are you". All messages sent (before and after my client replies) to x#xyz.com but should be received by all clients (my own client does not have a UI and can only respond to specific messages.).
Now I have already coded my client to reply automatically. This works fine. But the problem I am facing is that as soon as I reply (I use the smack library), all subsequent messages that are sent to x#xyz.com are received only by my XMPP client. This is obviously a problem as my own client is quite dump and does not have a UI, so I don't get to see the rest of the messages sent to me, thereby making me "lose" messages.
I have observed the same behavior with other XMPP clients as well. Now the question is, is this is a requirement of XMPP (I am sorry but I haven't read XMPP protocol too well). Is it possible to code an XMPP client to send a reply to a user and still be able to receive all subsequent messages in all clients currently listening for messages? Making my client a full fledged XMPP client is a solution, but I don't want to go that route.
I hope my question is clear.

You may have to set a negative presence priority for your bot..
First thing to know is that in XMPP protocol every client is supposed to have a full JID. This is a bare JID - in your case x#xyz.com with a resource in the end e.g. x#xyz.com/pidgin or x#xyz.com/home (where /pidgin and /home are the resource). This is a part of how routing messages to different clients is supposed to be achieved.
Then there are the presence stanzas. When going online a client usually sends a presence stanza to the server. This informs about e.g. if the client is available for chat or away for lunch. Along with this information can be sent a priority. When there are more than one clients connected the one with the highest priority will receive the messages sent to the bare JID (e.g. ClientA(prio=50) and ClientB(prio=60) -> ClientB receives the messages sent to x#xyz.com). But there are also negative priorities. A priority less than 0 states that this client should never be sent any messages. Such a stanza might look like this
<presence from="x#xyz.com/bot">
<priority>-1</priority>
</presence>
This may fit your case. Please keep in mind it also depends on the XMPP server where your account is located, which may or may have not fully implemented this part of the protocol.
So to summarize: I recommend you to look through the Smack API how to set a presence and set the priority to <0 for your bot client right after it connected.

Related

Strophe XMPP receiving only stanzas with full JID

I'm creating a web XMPP client to connect to an XMPP ejabberd server and I have the following problem:
My client can send messages just alright.
The problem is when I try to receive messages. I only receive stanzas directed to my full JID, that is including the resource I am using, so I don't receive stanzas directed to my user#domain but I do receive stanzas sent to my user#domain/resource.
This is not an ideal situation since the other clients I need to communicate with work with bare JIDs.
I have little experience with Strophe so maybe someone with more experience can illustrate what I'm doing wrong. Thanks in advance!
Have you checked if your xmpp server offers a setting to route messages to all resources?
OpenFire offers a property named route.all-resources which will forward messages to all resources for a person.
Also, you may want to adjust the priority of your resource, as only the resource with the highest priority will have the message sent to it (if the message does not specify a resource).
Here is an example of setting your resource priority to 10 with Strophe.js
connection.send($pres().c("priority").t("10"));
This article describes the intended behaviour, and also this answer from a related question may help you understand what's happening.

How does Google Talk replicate messages across devices?

I'm wondering how (official) GTalk clients manage to show all messages received - even if it was originally consumed by another client. For example: I'm logged into GTalk on gmail.com on my laptop and, at the same time, via the official GTalk app on my Android device. A friend sends me a message, which is displayed on both the gmail.com client and the Android client. (I think it's originally only forwarded to one of either clients, but the second client fetches the message later on)
I recently found out that there's a very similar XMPP feature, called Carbons. However, after a quick service discovery request Google's servers didn't advertise this feature. XEP-0313 and XEP-0136 look good too, but the servers don't advertise them either.
Possibly related question: Deliver Google Talk message to all logged in clients using XMPPPY
When you initiate a new chat then you should send the first message to the users bare Jid. This is what most clients are doing. When the GTalk server retrieves a chat message to a bare Jid it routes the message to all available resources. For all following messages in this conversation the clients normally pick up the Resource and send them to full Jids. The messages should not be replicated then.
Many other servers don't route message to bare Jids to all resources, but to the most available resource which is the client with the highest priority.
Here is a quote form the RFC:
If there is more than one resource with a non-negative presence priority then the
server MUST either
(a) deliver the message to the "most available" resource or
resources (according to the server's implementation-specific algorithm, e.g., treating
the resource or resources with the highest presence priority as "most available") or
(b) deliver the message to all of the non-negative resources.
XEP-0280 defines this. As I understand, it defines the mechanism to notify all the resources from same user when one of them sends a message to anyone. I mean, Alice/pda sends a message to Bob, so Alice/mobile and Alice/PC will receive a copy of the message sent be Alice/pda.
Hope it helps. I am currently looking for a server that implements this, and also for a client library. If not, I will implement it by myself in both jabberd2 and gloox xmpp library.
Cheers,

Not receiving own XMPP presence stanzas (for other resources) after sending initial presence

After connecting, when I send my initial presence to a server, the server does NOT respond with the presence information of the other resources for my own JID that are currently online (I do receive presence info for users in my roster though). I only receive presence info from my JIDs other resources when another of my resources changes status.
Is this standard behavior? I was under the impression that the server is responsible for sending this information after the initial presence.
I don't know which Jabber server version this running on so I'm not sure if this is a bug or a feature.
Is there any way to figure out what other resources are available for my own JID given this issue?
The server MUST send you also your own presence and the presence of all your other resources.
see: http://xmpp.org/rfcs/rfc6121.html#presence-initial
an entity is implicitly subscribed to its own presence
but I think there could be some extra wording about this in the RFC. Or maybe there is and I didn't see it ;-)
Alex

How does the persistence work in XMPP?

I'm trying to understand the differences between AMQP and XMPP and among other things I don't really understand if XMPP works like it had Queues.
When you send a message to various clients what happen if one of them is down? The server enqueues the message up to the client is up again or how does it work?
Thanks
It depends on the XMPP server implementation how messages and iq's are handeld when the JID is offline. Section 11.1 of RFC 3921:
Else if the JID is of the form and there are no
available resources associated with the user, how the stanza is
handled depends on the stanza type:
...
For message stanzas, the server MAY choose to store the stanza on
behalf of the user and deliver it when the user next becomes
available, or forward the message to the user via some other means
(e.g., to the user's email account). However, if offline message
storage or message forwarding is not enabled, the server MUST return
to the sender a stanza error. (Note: Offline
message storage and message forwarding are not defined in XMPP, since
they are strictly a matter of implementation and service
provisioning.)
For IQ stanzas, the server itself MUST reply on behalf of the user
with either an IQ result or an IQ error. Specifically, if the
semantics of the qualifying namespace define a reply that the server
can provide, the server MUST reply to the stanza on behalf of the
user; if not, the server MUST reply with a
stanza error.

XMPP server-to-server - traffic optimization?

I'm working on a design for a xmpp chat solution which involves some servers and where at least one server is connected with serious bandwidth limitations.
Assuming, we have two servers A and B, some users 0..n connected to Server A and some conferences 0..m provided by Server B.
Now assume, some users enter a conference room and a message is sent to that room. Will
Server B send this message once to
Server A and Server A distributes it
to the users or will
Server B send this message to each individual user of Server A?
According to the protocol spec, XEP 045, multi-user chat messages are reflected independently to each participant. I can't tell on a brief read if it is legal to send them server-to-server without reflecting. However, it might be worth asking this question on an xmpp.org mailing list, where the experts tend to hang out.