Let's say my goal is to create a chat service. I also want multiple, discrete chat rooms.
I am leaning toward using XMPP for scaling / load balancing. I read the article here, and I am looking at
Let's say I want to send a message from one client to another. According to this diagram,
1) The sender sends a message to Sender's XMPP Server.
2) Sender's XMPP Server relays the message to the MUC server.
3) The MUC server determines which server the recipient is connected to and relays the message there.
(correct me if I'm wrong)
Two questions:
1) The article suggests clustering the MUC over several servers. Does this mean a) mirror the MUC server's status over sender and recipient servers or b) turn the MUC section of the diagram into multiple servers, and the sender and recipient servers communicate with that cluster, transparently?
2) When a user first connects to a node, how does the network know which server to bind the user to? Is there a single point of entry machine to delegate this?
As far as entry point into the system are concerned, your clients will always use default entry points or the one you have specified in your DNS SRV settings i.e. user rcv and send data only via your xmpp server port 5222 (c2s) or 5269 (s2s).
So MUC message stanza flow will look like this (lemme know if i mis-interpreted your question):
a) if Sender/Receiver are both registered at your server
sender#myjabber.com <--> myjabber.com:5222 <--> muc.myjabber.com <--> myjabber.com:5222 <--> receiver#myjabber.com
b) if Sender is #gmail.com user and Rcvr #myjabber.com user
sender#gmail.com <--> talk.google.com:5222 <--> myjabber.com:5269 <--> muc.myjabber.com <--> myjabber.com:5222 <--> receiver#myjabber.com
Related
maybe anyone know solution.
I have multiple JID.
user#domain.com
user#domain2.com
user#domain3.com
15 JID, on public servers, and also have own jabber(prosody server)
can i split all that JID to one ?
Now i use PSI with multiple accounts, but I would like to use one and the other to forward messages to it.
And that the answer was from the account in which they wrote.
You may use xmpp-2-xmpp transport. It connects the other XMPP account(s) in your name and forwards (proxies) all messages etc.
There are two implementations that I am aware of:
J2J: http://wiki.jrudevels.org/Eng:J2J
Spectrum: http://spectrum.im (with Libpurple Jabber backend)
Unfortunately if you need to connect multiple accounts, you will need to set up multiple transport instances, as one transport instance allows only one registration per user.
Suppose that I have to write a UDP server which should receive authentication token for each client in the first message and then receive different data after some period of time. This UDP server should obviously check whether certain client authenticated previously or not. How should I do it? Should I store "authenticated" flag for each (IP addr, port) pair? Is it ok? If so, what will happen if several clients will have the same IP address (for example, they share it from the same internet provider)?
I think you can't. You'll need to have the token in each message. Multiple requests can come from the same IP, such as a client connecting from behind a NAT.
This a rare case where you might want to use multiple UDP sockets at the server and connect() each of them to one authenticated client, so that you can only receive further messages on each one from each authenticated client. You'll have to send the first reply via hat socket,a denture client will have to be written to adjust its destination accordingly after receiving the first reply.
When I send an email to somebody, (I think) my email is sent to my home server, then the email is sent to target server, then it is finally sent to the people I want to send to.
Sometimes, this needs multiple hops, which is the point that confuses me. Why does this need multiple hops? Why can't the email be sent to the target server directly? XMPP doesn't need multiple hops, for example.
A typical email transaction uses an outbound mail server, which looks up your recipient's incoming server, delivers it there, then that server hands it off to your recipient's mailbox server. That's 3 hops:
When you send a message, you connect from your email client (more properly: mail user agent, MUA) to your outbound SMTP server. This is the first hop, and your SMTP server creates a Received header denoting it for auditing later on. This will include the IP it sees you connecting on, a message ID internal to that specific server, and sometimes some other information.
Your outbound SMTP server then looks up the MX (mail exchange) record for each recipient's domain in DNS and connects to the highest priority relay it can find (the numerically lowest MX priority) for them. This is the second hop. As with any hop, a Received header is added.
The MX relay typically does anti-spam filtering, potentially rejecting the message during the SMTP connection. This is what generates a bounce message, which your outbound SMTP server sends you directly (if it's sent across the internet, it risks being backscatter, a form of spam, because the bounce cannot be proven to be legitimate). Often, anti-spam filtering is done later and the message is dropped silently or else delivered with markup.
The MX relay then hands the message off internally to your mailbox (IMAP/Exchange) server (hop #3). Sometimes, local mailbox server filters are used to handle patterns (or markup from the MX server) and facilitate various actions such as filing suspected spam into your Junk folder.
If you use a mail forwarding service, the MX relay instead passes your message to the forwarding target (another MX relay). This can theoretically go on for quite a while or even loop infinitely, but it should eventually end in a mailbox server.
See also the formal SMTP specification, RFC 5321.
If you use webmail, the web mail server is your email client. Some web mail servers add headers resembling Received headers to track the connection so spam filters can extend their reputation checks to the user rather than to the webmail system, which could be characterized as yet another hop.
In enterprise-grade environments, it is common for multiple layers of servers to be used for various purposes. These extra hops happen between the MX relay and the mailbox server and can be related to extra anti-spam or anti-virus handling, advanced mail aliasing, email archiving, internal mail routing between campuses, or any number of other things. These can for example ease transitions from one mail system to another (like migrating between versions of Exchange, which may require lots of testing and a slow migration so a problem doesn't affect the whole company).
Fundamentally that has to do with the original purpose of the Internet, or rather it's predecessor ARPANET, was designed to survive the loss of portions of the network (popular to popular misconception, this design goal existed not in order to survive nuclear attack, but because network components were rather unreliable at the time).
The packet switching network is designed to find one or more routes from where the packet starts (your email client) to where it needs to be (the email client of the person you are sending to).
In order to achieve that flexibility, the system is designed not just to route directly from point A to point B, but to find an available route (from a possibly very large set of possible routes) that is currently functioning.
If your email client had to know how to directly send to every other device in the world, without intervening subnets managing traffic, your computer would need a direct connection to every other computer in the world. That would be prohibitively expensive. Instead, routers inbetween accept packets from you and other people in your area and figure out how to route each packet closer to its destination. That's similar to the method that the airlines use to have regional flights feed hubs.
When a packet is being routed through the internet it will make multiple hops to get from source to destination.
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.
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.