My question is about XMPP protocol; which is considered to be use for real-time scenarios,
is it that real-time which is usually in context of multiuser games?,
can somebody please tell,
How or whether it's fits into the context the real-time multi-user games like the conventional TCP and UDP protocol or
is it totally different beast,
in which context it fits for games? and which kind of games, it supposes to support well
The XMPP protocol doesn't have anything to do with game servers. XMPP is a de-centralized chat protocol in which everyone can set up their own server. Of course you could synchronize your real time multi user game using messaged parsed from this chat system, but that would incur a lot of overhead (since XMPP uses long XML messages that are usually not encoded*.
A better/more usual way of doing communication in games is by building your own binary format that stores game state changes and sending this to a server using an UDP socket (be careful to time stamp your messages so that you can drop late messages, also incorporate in your design that some messages might get dropped). The server should check if the state change is valid and then redistribute it to the other clients. This gives you a low overhead protocol, but UDP does not guarantee ordering and delivery so for critical, but infrequent, messages you should use a second socket that sends messages over TCP (for example chat messages).
Now this might seems like an awful lot of work, but there are quite some code samples, and even packages for JAVA and other languages that have this server/client architecture set up for you, so you only have to send the messages.
*there are some XMPP extensions which compress/encode messages
Depending on your latency and throughput requirements Xmpp may or may not be useful. If you were to write an internet distributed game, with social aspects and low content updates (say farmville) Xmpp would be useful, since it allows for easy scaling of many simulatenous users, tracking their online status, direct messaging between the users and the game components, etc.
For something fast paced, the overhead of the protocol likely makes unsuitable.
In the context of tcp/udp, xmpp is an xml stream protocol on top of tcp with centralized, but federated servers.
Related
I'm developing an Android app that requires 2 (or more) devices to communicate with each other.
I tried using Google Cloud Messaging but I was disappointed to find out that the GCM max capacity is 100 messages, so it is broken and does not fit my requirements.
I was thinking about java sockets. Every device will open a new socket (or keep its socket open) and communicate with a group of sockets (devices).
In order to communicate this way I need a server-side app that can send messages to the client (android device). So I figured out that HTTP or web-service won't help me. Am I right?
What is the best way for me to implement such a server-side app?
You can refer to this question I previously asked and implemented. It was for implementing my own Notification mechanism but it equally (or even more) applies to chatting applications since message queues perfectly fit that usecase.
Building an Android notification server
I ended up not doing it and using GCM at the end but I did have a fully working solution using ActiveMQ and Paho. You can research them both and understand their inner workings. It's easy in principle and definitely possible but the problem is, you may not be able to do this for iOS or WP as it requires running a service in the background (in case your app is not open and you want to make sure the messages are at least sent in a notification).
The possible solution to that problem would be to use both the notification service (GCM or equivalent) for background notifications and then using your MQ for actual communication but I decided that was too much for my project.
If you look at Paho, it will have a fully working MQTT solution that will work even if the phone is not "online" (sleeping or otherwise) and there are plenty of samples for ActiveMQ and drivers for multiple programming languages.
I think this solution is much better than having open sockets between two apps, at least because they allow you to persist messages and guarantee delivery which is an important aspect for a chatting application.
As it is said by kha, choose one of the message queue protocols is the best solution. 3 reasons in brief,
Delivery guaranteed regardless of temporary offline or long latency.
As simple as subscribe / publish, no worry about transport layer any more.
Broker available online. You save time and money for setting up your own.
For mobile devices like in your case, I'd prioritize MQTT too. It's lightweight and stable. If you are totally new to message queue or MQTT, refer to this documentaion and example code
I have a concept of a game system that includes (preferably) Java server and multi-platform clients (Web, Android, iOS).
This is a 1vs1 player-vs-player realtime game. Servers performs a matchup of 2 players. So basically server needs to handle many matches containing 2 players. Both players alter same data, and each player should be updated in realtime with actions of other player.
Can you suggest me:
1) Server-side framework/library that would ease the implementation, as I would rather not start learning node.js from the scratch. :) Vert.x comes to mind.
2) Should clients hold the replica of the data, and alter it locally (meaning only data that is transfered are only commands, here I see JMS as good solution), or should only server alter the data and then send the complete data set every time change occurs?
3) How should the data be transfered? Considering the multi-platform requirement only thing I see viable are WebSockets.
4) An example/tutorial of server handling pairing of WebSocket connections? All I ever found are 1-to-1 connections.
5) Considering scalability, can you explain how could all this work in a distributed environment?
1) I don't think node.js is such big deal to learn. I would personally prefer a well known - broadly used framework.
2) If you are considering mobile, probably the first option seems more sound. You should consider send/push deltas during the game, and still provide functionality to retrieve the full state of the game in case the client disconnect and connect with same ID.
3) WebSocket would be the best option. Push approach, TLS option and well supported. Another option is the WebRTC data connection, that is peer-2-peer most of the times. I say most of the times because if one of the users is behind a dynamic NAT router or restrictive firewall, it won't be possible, and you will need a TURN (relay) server. Anyway, it is less supported than WS.
4) You should not "pair websockets". The WS connections just input commands to your logic, and your logic broadcast events to whoever it wants. Despite of being a 1vs1 game, probably you want to inspect the flow of events for further debugging or analysis. So consider WS as a transport, not as an entity.
5) Very, very, very broad question. But assuming that you are going to use WS, and that your application will be so successful that you will need multiple servers... assume that it is impossible to predict that two users will connect to the same server, so you should consider a message bus that allow to play users from one server with the users in other server. An EDA (Event Driven Architecture) would make sense.
In my knowledge, most of android tutorials and examples out there rely on use of GCM for sending data from server to android device; and use php scripts along with post/get methods to send data from device to server.
A friend of mine(someone who doesn't have any knowledge of android programming) simply asked me, why can't we use Socket class in java? In traditional java programming, you use sockets (IP adress + port no.) to achieve functionality similar to GCM (single server multiple clients - using proper techniques you can ensure messages are not lost, just like gcm).
Can this traditional socket approach be implemented in android as well? If so, what are the pros and cons of GCM and Sockets? In which situations would the use of sockets be appropriate?
Whatsapp and lot of other apps, to my knowledge, use GCM. Are there apps which use sockets?
P.S: I'm just a C.S. student; apologies if I've got my concepts wrong somewhere
GCM uses sockets too. However, they are managed by the system and thus can do things a regular app cannot do. Generally, for any type of 'push' notifications, the system needs to have a long-lived socket, and a 'notification' is just some data received on that socket. All of this is not too hard to implement on an always connected machine, such as a desktop or a server, but there are additional challenges on mobile. For example, switching networks (3G<->WiFi), going out of range, maintaining a connection without keeping the device awake all the time (and killing the battery in the process). So yes, you could implement something similar using a service , sockets and your own server, but it's not trivial on mobile.
Check out http://mqtt.org/ for an open-source implementation.
Let's consider application using WebSockets which can be divided into several, independent modules. A simplest example would be chat application where client app can join/connect to several chat rooms at once (each chat room is independent from each other). What is the preferred aproach of organizing the connections while developing such application
Open new websocket connection in client for each chat room. This way you'll have multiple instances of javax.websocket.server.ServerEndpoint on the server side, each with different url. Both the server and client apps will thus be a little bit less complex and can be separated into functional (reusable) blocks. The drawback is that the client will have to keep multiple opened connnections at once. In my case we're talking about up to ten max at a time.
Open one websocket connection and multiplex the messages to chat room underneath, i.e by field with chat room id in the messages. Not a big deal to implement, will make the app a little bit more complex, but is it worth it?
What is the preferred approach?
This is not easy to answer generally, for it depends on your specific setup. However, here are my thoughts on this:
I think option 2 is the better approach, because open connections are really a limited resource for many webservers. Remember, that a websocket connection is different from a regular http request and stays open over a long time. The additional complexity of the multiplexing protocol is really not an issue I think. All implementations I know of websocket communication protocols use the latter approach, although I must admit to not know really many examples.
Wikipedia defines XMPP as:
...an open-standard communications protocol for message-oriented middleware based on XML.
xmpp.org defines XMPP as:
The Extensible Messaging and Presence Protocol (XMPP) is an open XML technology for real-time communication, which powers a wide range of applications.
Although I'm sure both these definitions are very accurate, they don't tell me a thing about what I - a Java developer - can actually do with XMPP!
For instance, I've heard XMPP can be used with message-oriented middleare (MOM). How so? Can XMPP somehow integrate with my Apache Camel routes, my ESB or some SOA implementation to deliver a better/faster/more robust business tier? If so, how?!?!
A good, King's-English explanation of XMPP, along with some practical examples (preferable MOM-centric) would be greatly appreciated. Thanks in advance!
XMPP can be used for a wide range of messaging based applications. Basically, it provides core services which can be used to build XML based messaging applications. Its based on a decentralized client-server architecture and utilizes long-lived TCP connections for communicating...
core services include...
channel encryption, authentication, presence, contact lists, one-to-one messaging, multi-party messaging, notifications
service discovery, capabilities advertisement, structured data formats, workflow management, peer-to-peer media sessions
textbook use cases...
instant messaging (using presence, contact lists, one-to-one messaging)
group chat, gaming, systems control, geolocation, middleware/cloud computing, data syndication
bots (weather, database interface, system monitoring)
messaging modes/patterns...
point-to-point messaging is used to send to a specific receiver
multi-user messaging is used to message to a group of receivers
publish/subscribe support is used when there are large volume of events and systems are interested in differing subsets of events. Publishers put events into topics and subscribers indicate which topics they are interested in. This decouples the publisher/subscriber and allows for scalable real-time messaging. For more information, see this article: http://www.isode.com/whitepapers/xmpp-pubsub.html
deployment methods...
XMPP user - connects as a normal user and responds to requests addressed to the user
XMPP Server plugins - deployed as part of the server plugin architecture
XMPP Components - service external to an XMPP server that connects and behaves like a plugin
Java Integration
Smack API - A pure Java library, it can be embedded into your applications to create anything from a full XMPP client to simple XMPP integrations such as sending notification messages and presence-enabling devices.
Camel XMPP - A Camel component that allows integration with Smack API in Camel routes
To your specific question "can it be used in SOA/middleware?"....
yes, it can be used to wire together applications via XML messaging and XMPP APIs
whether its the best technology choice depends heavily upon requirements
one good use case, interactive system monitoring/management...here are some other examples
Also, XMPP integration with Camel is trivial. See this camel-xmpp unit test for a basic example of interfacing with a Google Talk server. Also, Camel's framework allows you to build an application and easily swap out different messaging technologies (JMS, STOMP, mina, etc).
I can start combining information from al kinds of sources found on the internet using Google (keywords: XMPP Java MoM examples), rewrite (or even copy) the definition of XMPP, but of course I will not do so. There is just too much. I also do not have examples available for you.
Below I will list the links I found most interesting, so you can start reading and get more knowledge on the subject.
1) http://www.xmpp.org/
This is probably the best starting point. Browse through the menu left to right and top to bottom. That is what I did. The site lists servers, clients and libraries, so you should be able to find the desired examples this way.
2) http://www.ibm.com/developerworks/webservices/library/x-xmppintro/index.html
Clear article, which also mentions MoM. No Java examples, but Ruby.
3) http://fyi.oreilly.com/2009/05/what-can-you-do-with-xmpp.html
Maybe you should just get the book? No examples in the article.
4) http://kirkwylie.blogspot.com/2008/07/real-mom-is-hard-lets-use-xmpp.html
Interesting article where the last line basically says: Why use XMPP if you can use AMQP or JMS?
I hope this helps you I finding what you need.
XMPP is an open and extensible standard for real time communications.
XMPP comes with a core that is defined in its rfc, which describes the basic protocol for doing instant messaging and exchanging presence information. However where XMPP really shines is in its extensibility: XMPP defines the building blocks (presence, message and iq stanzas) to create protocols of communication. These typically come as extensions. A list of currently available standard extensions can be found here. The most important of these are typically available for all the popular XMPP servers.
It is exactly this extensibility that makes XMPP appropriate as message-oriented middleware.
Let me take as an example Publish-Subscribe which is a typical pattern for middleware and becomes a necessity as soon as you depart from the scenario with a few entities where simple messaging is adequate. PubSub is used in situations where entities, or producers, produce information that is to be consumed by other entities, the consumers. Typically, the information is written to nodes, to which consumers are subscribed. Being subscribed they receive notifications when an item is added/updated/deleted. An incredible amount of use-cases can be elegantly covered by PubSub, from queuing long-running jobs and having workers handle them, to micro-blogging. XMPP has a very robust and widely available extension to handle PubSub in a standard way, described in XEP-0060 and providing out of the box a workflow for handling publishing, subscriptions, notifications and security. Having a look at the use-cases in the XEP will give you an idea for the simplicity of the whole thing.
Now, while most use-cases are covered by using (or abusing) existing standard extensions, eventually you might need the little extra custom protocol that is not covered elsewhere. Using your language of choice you can write an XMPP component defining your own protocol. You then connect the component to the XMPP server you are running and by using simple namespacing let the server know what kind of messages you can handle and let the server advertise your protocol capabilities to clients connecting to it. There is no end to how simple or complex you can make this. Lack of better example but maybe good enough for illustration, here is a component I wrote that leverages XMPP to do real-time collaborative editing in the Plone CMS (similar to Google docs). While the details can get complicated I think having a look at the "Protocol Specication" on that page will give you an idea.
Finally, concerning Java specific libraries as #boday mentions, there are libraries around that make it easy to start with as well as Apache Camel integration (although it only does simple messaging as far as I can see). Keep in mind though that the investment in understanding how XMPP works and being able to go beyond using existing libraries is really worth it and can lead to extremely powerful and yet simple integration.
Let me just give you a good overview of what XMPP is ?
XMPP ( Extensible Messaging and Presence Protocol )
It is a Real time communication protocol.
The first IM service based on XMPP was Jabber.org
One XMPP binding is BOSH. Others include TCP and WebSocket.
BOSH is "Bidirectional-streams Over Synchronous HTTP", a technology for two-way communication over the Hypertext Transfer Protocol (HTTP).
BOSH emulates many of the transport primitives that are familiar from the Transmission Control Protocol (TCP). For applications that
require both "push" and "pull" communications, BOSH is significantly
more bandwidth-efficient and responsive than most other bidirectional
HTTP-based transport protocols and the techniques known as AJAX.
BOSH achieves this efficiency and low latency by long polling.
How does XMPP works?
XMPP achieves low latency by implementing Long polling.
What is Normal Polling and Long Polling ?
NORMAL POLLING:
Consider the old chat apps that used normal polling. Here the top of the graph indicates client side. Bottom indicates server side. Let the timeout be 5 min.
Client asks the server : " Is there any new message for me ?"
Server Responds : "No ! "
After 5 min
Client asks the server : " Is there any new message for me ?"
Server Responds : "No !"
After 1 min
Client Receives a message
After 4 min
Client asks the server : " Is there any new message for me ?"
Server Responds : "Yes! " + message.
LONG POLLING
The top part of the graph is client . Bottom part is server.
Client asks the server : " Is there any new message for me ?"
Server Answers : "No ! But you may soon receive a new message, so let me just hold your client state for 5 min in the server."
After 5 min
Server Responds : "No !"
Client asks the server : " Is there any new message for me ?"
Server Answers : "No ! But you may soon receive a new message, so let me just hold your client state for 5 min in the server."
After 1 min
Client Receives a message
Server Responds : "Yes! " + message.
You can see clearly, how instantaneously the communication happens.
You can read more about XMPP HERE
In case, if you are curious to set up your own XMPP server, read this.
XMPP is fundamentally a protocol for chat room clients to talk to a chat server. Camel does allow you to integrate with XMPP so that you can consume messages from or produce to such a mechanism http://camel.apache.org/xmpp.html
When you start talking business tier, ESB, SOA etc. and MOMs you're probably looking for a messaging mechanism that supports point to point and publish subscribe messaging. You're probably also thinking about things such as guaranteed messaging, high availability, and fine-grained security. You won't get these from a mechanism that reads and writes text messages into a chat server. A messaging platform such as ActiveMQ is likely to be a far better fit.
There are very few instances where I would contemplate using XMPP with integration mechanisms, maybe as a notification mechanism to a dev chat room, or as a duct-tape mechanism for controlling servers that monitor a chat server for instructions.