I am new to xmpp/ejabberd and also to testing. I have an ejabberd xmpp server setup for my chat application.
I am using Tsung to do load testing on the server.
For this I am creating multiple scenarios or sessions where the Tsung will create MUC and send messages to that MUC.
It works fine, until a question came to my mind.
The tsung does the load testing, and generates the reports too, but why isn't the rooms that are created by tsung and the messages that are sent to those MUC does not reflect on the Server.
I have checked it using ejabberd rest APIs. I don't see any rooms created by tsung. I can assure that the xmpp server works fine as I have created rooms and sent messages from my chat application.
Is it that the tsung only creates dummy data that it later delete once the test is complete?
Or like its said on their docs that it simulates traffic. Does that mean it does not create any of those data?
Or is it with my tsung configuration?
I am sorry if this sounds silly.
Thanks in advance!
why isn't the rooms that are created by tsung and the messages that are sent to those MUC does not reflect on the Server.
Well, this should appear in ejabberd log files.
But other than logs, loadtesting doesn't leave any information in the ejabberd database after testing. And why not? For a simple reason: by default rooms are temporary, not persistent. A room is created when an occupant joins a new room. And the room is automatically destroyed when the last room occupant leaves the room.
See https://xmpp.org/extensions/xep-0045.html#exit
Note: If the room is not persistent and this occupant is the last to exit, the service is responsible for destroying the room.
As you can see there are functions to join and leave the room, no need for create and destroy them:
https://github.com/processone/tsung/blob/develop/src/tsung/ts_jabber_common.erl#L700
Related
Socket.io offers first-class support to address specific recipients by using rooms
I'm creating a webapp where the server passes notifications to the user via Socket.io. It is a marketplace. Users may favourite/buy/sell articles and will therefore be notified from the server when something changes.
Now I've got to make the choices whether a user joins a room for every article he is interested upon login or whether I emit a message for every user individually when something changes.
What is more efficient? Is there a best practice? Am I taking on this problem from the wrong perspective?
Rooms are only a construct on the server for keeping track of lists of sockets. When you broadcast to a room, all the socket.io code does is loop through the list of sockets and send a message individually to each one.
So, in either of your cases, a message is being sent individually to each socket - same for both. Use rooms if the mechanism for keeping track of groups of sockets and being able to easily send a message to each one is useful and works for your purpose.
If you have some reason to want to use your own data structures for keeping track of lists of sockets, then that's fine too and it won't cost any more to loop through it and send a message to each one as long as you have an efficient scheme for finding which sockets you want to send the message to.
From the spec —
7.14 Exiting a Room
In order to exit a multi-user chat room, an occupant sends a presence
stanza of type "unavailable" to the <room#service/nick> it is
currently using in the room.
Example 80. Occupant Exits a Room
<presence
from='hag66#shakespeare.lit/pda'
to='coven#chat.shakespeare.lit/thirdwitch'
type='unavailable'/>
This implies that as soon as the user disconnects from the XMPP server, he is removed from the group on the server side. The issue is simple — I don't want this behavior; I want a behavior that is similar to what Whatsapp does, i.e. even if the user goes offline, he is still part of the MUC room (which is configured to be persistent on the server side) and will receive messages from other occupants.
Given the spec and the documentation for XEP-0045 and XMPPFramework for iOS, I have no idea how to accomplish this or if it's possible to accomplish this in the traditional ejabberd server.
XEP-45 was designed more then 10 years ago. Back then, the designers had something like IRC channels in mind. Everything of XEP-45 is designed based on the assumption that a user enters and leaves a room when he/she starts/terminates its client.
WhatsApp Groupchats are different: A user joins a groupchat is is able to view the (complete) history of that chat. Even if the users client is offline/unavailable, he is still considered part of the groupchat.
The XMPP community currently works on a new XEP that provides such functionality. It is called XEP-0369: Mediated Information eXchange. It is the spiritual successor of XEP-0045, providing the features one would expect from modern groupchats.
You could emulate something quite like this by using server-side history of the MUC (Message Archive Management, XEP-0313), so that when a client logs in they're able to request the history of the MUC while they weren't in it.
If you also want to be able to show the offline pseudo-occupants of a room, the easiest way to do this is probably to map a pubsub node per room to store the list of these pseudo-occupants that clients could read to supplement the usual occupancy list.
There are probably other solutions here, but those that come immediately to mind for me involve changing the behaviour of the server in non-standard ways, such as allowing normal occupants to query a membership list, which normally only admins can do.
The Whatsapp model is much simpler than you imagine - they just maintain user session online even if user disconnects, and re-sends messages when he "reattach" session. XEP-0198 introduce similar concept to traditional XMPP sessions. You only need to configure longer inactivity period (typically XEP-0198 assume 300 seconds, but whatsapp-like messengers holds session 24+ hours)
Yes you can make your group persistent by setting its configurations this way:
NSString *var = [field attributeStringValueForName:#"var"];
if ([var isEqualToString:#"muc#roomconfig_persistentroom"])
{
[field removeChildAtIndex:0];
[field addChild:[NSXMLElement elementWithName:#"value" stringValue:#"1"]];
}
I'm trying to create a server app in node.js, where multiple clients connect, and then one sends data, and that data gets send to another specific client. Which client it gets sent to is determined by a 'user id' that all clients will send after they connect.
How can I keep track of clients as they connect? How can I find my specific client? I realize this is a very broad question, but any pointers would be appreciated...
Thanks!
Have a look at some of the existing open source node servers like Socket.IO.
Socket.IO basically assigns each client a unique id. Ids are stored in a hash which is then used as a lookup to identify specific clients - you can create channels as well as broadcast to all connected clients.
I'm currently looking into XMPP and I would like to know if there is a way to create dynamic XMPP rosters. I want the contact list of any user be automatically generated by the server / component / plugin.
Can components access and modify rosters?
I know that some servers (like OpenFire) use an external database to store these information but if I modify the database, I don't think the users will be notified in realtime.
Are some people already doing that or do you have an idea how to create it?
Thank you for your time.
In most XMPP servers this is called "shared roster groups".
I can't comment on Openfire in particular because I haven't used it for a long time, but I don't think I know of a server currently in which external roster changes are instantly transmitted to clients. Usually the client will simply pick up the new roster when it next logs in.
It would be possible to push the updates instantly to clients using what XMPP calls "roster pushes". This would require quite some work on the server though to identify what the changes are between what each client knows the roster to be, and what the new roster is, and then transmit just the changes.
If you really need this then a server plugin would probably be the way to go, or pester your server developers for the feature (I know that as a Prosody developer I've already been pestered, and this is something I'm planning to work on).
As for whether components can access users' rosters - this is dependent upon the server implementation and configuration.
I am builing a win application that has user access control against a sql db, all the data is stored in this db as well.
This project is to be installed in one site on 30-40 machines (I mean to say that it's not web, it's all in one place, maximum call it intranet).
I want that while the program is logged on, the logged-in user should be able to chat to the other logged in users.
Any recommended approaches in C# & VB?
I would appreciate any idea, link or tip.
Please share me with your experience
Thanks!
NOTE: The program is in Wpf if it does matter.
Architecturally, it seems like a publisher-subscriber message bus would be a good pattern for you. You would have a centralized server that each client would register with that will distribute notifications from publishers to subscribers.
Each client will register for notification of the client list upon starting. Each client can register interest in being notified when another client publishes a message. Each client would publish messages to the bus to be delivered to any subscribers for that client.
There is a good example of a pub-sub message bus written in WCF in MSDN: WCF ESSENTIALS What You Need To Know About One-Way Calls, Callbacks, And Events. You could get this up and running fairly quickly.