There is a game that currently is played on standalone computers.
I want to create an add-on that allows the players to interconnect. For that I think XMPP seems to be a suitable platform.
The messages that shall be exchanged is presence/roster so users can find each other, structures messages to send items or money and generic text messages for comment and fun. In later versions I'd like to experiment with some 'business logic' to send out global changes for the world or missions and such.
My question is how users get hooked up to each other. Imagine someone creates an XMPP account. How does he start meeting the others?
Or, in general how would the users see each other if they have independent accounts? Should they all join one first multi-user-chat? Should there be one monitoring component to send invites and update rosters?
If, inside the game players can enter different areas, would it make sense to have one multi-user-chat per game area?
I know these are many questions but maybe from them you get the design problem I am facing, and I'd be happy to get some clues how this could get implemented.
Meanwhile I found the answer.
The game acts as XMPP client. It sill connect automatically to a multi-user-chat that is hardcoded in the game. With the correct parameters given, the XMPP server will create the chat room on the first user to connect. Subsequent users will simply join the same room.
This given, every user will automatically receive presence messages for all users in that room. From this the client knows the other player's addresses and can send messages to specific players. Messages addressed to the room will automatically be relayed to all other users.
So the problem I saw above is actually very easy to solve within XMPP.
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"]];
}
Using OpenFire 3.71, I have a couple of different conference services, each has a couple of chat rooms in it.
Now I want to broadcast messages to all the MUC ROOMS within one of the services and not as "private messages" to the individual users in those rooms/services. (It should more or less look like as if I entered every single room, sent a message, and left...)
Is that possible in some way? Is there a plugin already? Or is at least possible to write such an plugin? I'm not really sure how the MUC's work...If somebody knows a good source for that, that would be nice to read too...
Thanks,
Jens
I figured out a workaround, in case anybody needs something similar:
I implemented the clients now in the way that they will automatically join a default (per service) muc in addition to the room they join manually. In this default room, only the "owner" can send messages and once the client receives a message in this chat it is displayed within the room that s/he is "actually" in...
As usual for "workarounds" it's surely not the best solution, but it works for my purpose...
If you know of a better solution please let me know.
I'm designing a net-game that needs to support thousands (even tens of thousands) of end users.
* The client side is browser-based.
* The server side "engine" will be based on XMPP with MUC functionalities.
* The game is made of many scenarios (dozens to hundreds), where the end-users (the players) join in order to take part in that scenario.
* Every scenario must have a unique "bot" that controls the flow. For example: player X casts a spell at player Y: the bot receives the "cast spell request" BEFORE the rest of the room, calculates the result and "notifies" the rest of the scenario participants regarding what's done (player X fired, player Y hit...).
My questions are:
1. What XMPP server would fit best for the job?
2. What server-side language can support a near real-time "messaging" for the expected amount of players? (24/7, multiple "rooms" [scenarios], tens of thousands of end users).
3. If we assume that each scenario should be able to host up to 100 users, and that we need a bot to be present in each scenario to respond to the players' actions and "deliver" them to the rest of the participants in that scenario, what would be the best approach:
A. Use MUCs with a bot created for each room, joining as a user, or:
B. Use PubSub or other methods.
I had a similiar scenario for my project. i used ejabberd as server, and strophejs for client side. On the server side I used java since it was familiar for me. I used whack library.
Here are the thing i did.
created an external component which will listen on some particular port.
Whenever a client wants join a game, it will send a message to the component
upon recieving message, the external component creates a new room, and joins in the game as bot.
This component implementation will give listeners for messages, presence notification, etc.So component or bot can act upon each message or presence.
When there are no users left in the rom , room will be shutdown.
So far I managed complete a working demo, the product is not full yet.me too finding some difficulties..:-)
I am helping a Los Angeles choreographer to transition away from sending her announcements via Entourage.
Here's the situation: She has multiple conact groups, and sends classes and performance announcements several times a month, to different groups.
She manages the contact groups manually. The group size is between 1500 and 2500 people.
Recently verizon blocked her outgoing port 25, presumably for spam activity. Again, her contacts are interested in the content.
She is aware of mailchimp, constantcontact etc. but would like to be able to send the email via her email software and not have to create a newsletter for every single mailing. Also, she's very short on $$.
So, what would be the best way to set up a system allowing her to send announcements from Entourage, with attached images, to her lists, without having Entourage send every single email?
I am thinking of setting up a set of mailing lists, each corresponding to one of her groups. I have never set up a mailing list before and am wondering if it's possible to have a list accept emails from only one person (Admin) and distribute them to the group?
Recipients should be able to unsubscribe easily, and by default reply to her but not the list. She should be the only one able to use the list for distribution, and should be able to send messages (with attachments) directly from her email client without modification.
Is this possible? Where can I find step-by-step instructions? What are best practices to avoid her domain being blacklisted? What's the easiest way to convert her contact groups to mailing list subscribers?
I am helping her for free, so the simpler the better :)
Thank you!
UPDATE: She has a standard linux hosting account allowing her to run php etc. And, ideally, the emails would come from her personally or at least from her domain name.
Does she have web hosting? If so, PHPList is a decent piece of software that allows you to create and manage multiple lists, save message templates, and throttle outgoing messages to appease spam blockers.
I believe Google Groups will accomplish all of your requirements.
http://groups.google.com