I want to set up a server for broadcasting same message to multiple users at the same time. I went through the GCM official documentation, it says that - "XMPP" does not support "multicasting" (sending same message to more than one user). HTTP could be used for that.
If that is the case, why there are a lot of articles on XMPP implementation and none on HTTP.
It makes me think that XMPP might be used as well.
Please suggest which one to use. If HTTP is the answer, share some links that explain the implementation.
GCM XMPP interface does not support putting a list of recipient for a single push, but you can still send several pushes in parallel (on the multiple XMPP connections you may have).
For sending push notifications, what is typically more efficient depend on your usage pattern:
If you send a lot of notifications to many users, XMPP may be better, as you can have several parallel streams.
If you typically send the same notification to many users, then HTTP may be more efficient as a single notification can reach 1000 recipients at once.
As suggested, if your usage pattern is multiple, you can use both and select the most efficient approach dynamically.
However, it may not be worth the effort as you really need to send a lot of notifications to see a difference. Give you mention sending notifications to multiple users, my own personal suggestion would be to use the simpler HTTP approach and try the XMPP connector of GCM if you feel this becomes a bottleneck for some part of your usage.
Related
So, there we've got a client-server interaction via ZMQ and have stucked into an architectural arguing about the proper pattern fitting our needs. I hope that someone wise and experienced may help resolve it.
It's not essential, but I need to mention that ZMQ is not being used directly, it's rather a Qt binding with C++ over the library itself, so low-level customizations are possible but undesirable (they would increase implementation efforts significantly).
Current architecture
There was a need of some reliable, convenient & robust API broker, the one's been implemented via REQ <-> REP: statuses, error codes, encryption, etc. Encryption 's been implemented via separate authorization SSL channel, providing API with session keys, it's mentioned here to empasize that as far as SSL has not been provided at ZMQ's socket level (looked too complex), "session keys" exist (symmetric encryption key per client), it limits pattern solutions somehow.
So, there exist requests (client) + responses (server), it works. But we've recently met a need in some notification mechanizm for clients. Let's say the current broker API provides some types of data: X, Y, Z (lists of something). The client can get any of them but it has to be notified when any changes in X or Y or Z occur in order to know that new requests are to be done.
The problem
Obviously, clients should receive either data updates or notifications that such updates exist. It could be a mere PUB-SUB problem, but it seems almost impossible to make this solution encrypted, or at least authorization-aware (not mentioning really "crutchy" ways to do it).
After some discussion two opinions appeared, describing two different workarounds:
Still use PUB-SUB, but only send notification type to the subscribers, like "hey, there's new X present". Clients-subscribers would have to perform already implemented API requests (REP-REQ) with session keys and all. Advantages: easy and working. Disadvantages: client logic complication.
Just rewrite API to use couples of ZMQ_PAIR sockets. Results in client-server behavior similar to plain sockets, but notifications can be "sent back" from server. Advantages: simple scheme. Disadvantages: rewriting, also broker won't differ much from a simple socket solution.
Question
What would you adwise? Any of the descibed solutions or something better, maybe? Possibly X-Y problem exists here? Maybe something is considered a common way of solving problems like that?
Thanks in advance for any bright ideas.
ZMQ_PAIR socket are mainly used for communication between threads so I do not think they are a good solution for a client/server setup, if it all possible.
You could use ROUTER/DEALER instead of REQ/REP as they allow other patterns than just request/reply. I think newer version of ZeroMQ provide SERVER/CLIENT as a better alternative but I have not used them myself.
However, I would prefer a solution with a separate PUB/SUB channel because:
You don't have to change the existing REQ/REP protocol.
It allows only clients that are interested in notifications to connect to the PUB socket and process notifications. Other clients can use just the existing REQ/REP protocol.
PUB/SUB can automatically send notification to multiple clients.
PUB/SUB allows subscribing to specific notifications only.
I'm going to implement a mobile game for Android and iOS in which each players' actions need to be broadcasted to other nearby players (nearby in the game) through a server that checks if the actions are permitted. The requirement is that the other players need to be notified about these actions as soon as possible. The actions don't need to be delivered in the order of sending, but the delivery should be reliable.
I'm considering using ZeroMQ to implement that. Nearby players could subscribe to the the same topic and publish/consume messages that contain other player's actions. Using a message queue seems to be very attractive compared to implementing the communication using some kind of RPC. I have the following doubts though:
Would ZeroMQ work well over a cellular network which isn't very
reliable?
ZeroMQ doesn't support sending messages using UDP, only
TCP. I don't require the messages to be received in an order. If a
message is lost, I'd like the receiver to be able to process the
messages that followed the lost one without waiting until the lost
one is resend. Is it possible to achieve that using ZeroMQ?
As an alternative, I was considering using ProtoBuf with Netty for example, with UDP + reliability implemented on top of that. However, this would be more work and I'm not sure if I'd be able to achieve better performance than ZeroMQ which is considered to be great in that matter.
Actually, is UDP communication over the cellular network/Internet a good idea? Wouldn't there be any issues with operator's firewalls, NATs or so? I'm assuming that it should be fine, since the communication is through a public server, not peer to peer.
Is there any fast and reliable message queue that supports UDP?
Consider a web application such as Google Chat, where the servers serve hundreds of millions of clients simultaneously. In such application, the servers have to push notifications to clients at near real time (in the chat example - incoming messages, presence notification etc.).
How do they implement it? Significant part of the clients are browser based. I suppose polling would overload even Google's servers. So, are they using something like Comet? If so - do they need to allocate a server for every 65536 clients (maximum TCP connections per machine)? I understand that there is a way to circumstance this limitation but I don't know how it's implemented.
Chat is not handled by single application / hardware / instance.
They definitely using many instances with load balancing that allows to scale chat system horizontally. It might be dedicated for regions or just single clustered system (I believe it is dedicated within regions but still clustered within region).
As well you can have as many connections as hardware and network will handle but not 64k.
Because 64k (actually less then that) is regarding Binding sockets (server sockets, but not client ones).
In case with google and based on supported browsers, they definitely use mixed technologies to communicate selecting the most powerful based on browser support. That can be long-polling, sockets and even oldest one: simple ajax.
As well for example facebook chat is based on erlang. And using erlang there is many examples having more then million connections.
I don't know how Google handle this, ans they probably won't tell us. But, today you can deal with http streaming, websockets or long polling to build such application. To give you an example Atmosphere framework
is a tool to build "real-time", efficient and scalable web application.
I am sending small messages consisting of xml(about 1-2 KB each) across the internet from a windows application to a asp.net web service.
99% of the time this works fine but sometimes a message will take an inordinate amount of time to arive, 25 - 30 seconds instead of the usual 4 - 5 seconds. This delay also causes the message to arrive out of sequence.
Is there anyway i can solve this issue so that all the messages arrive quickly and in squence or is that not possible to gurantee when using a web service in this manner ?
If its not possible to resolve can i please get recomendations of a low latency messaging framework that can deliver messages in order over the internet.
Thanks.
Is there anyway i can solve this issue so that all the messages arrive quickly and in squence or is that not possible to gurantee when using a web service in this manner ?
Using just webservices this is not possible. You will always run into situations where occasionally something will take much longer that it "should". This is the nature of network programming and you have to work around it.
I would also recommend using XMPP for something like this. Have a look at xmpp.org for info on the standard and jabber-net for a set of client libraries for .Net.
Well this is a little off target, but have you looking into the XMPP (Jabber) protocol.
It's the messaging system that GTalk uses. Quite simple to use. Only downside to it, is that you will need a stateful service to receive and process the messages.
I also agree with #Mat's comment. It was the first solution that came to mind, then i remembered that I used XMPP in the pas to acomplish fast/ small and reliable messages between servers.
http://xmpp.org/about-xmpp/
if you search google you will easily find .net libraries which support this protocol.
and there are plenty of free jabber servers out there.
One way to ensure your messages are sent in sequence and are resolved as a batch together is to make one call to the webservice with all messages that are dependent on each other as a single batch.
Traditionally, when you make a call to a web service you do not expect that other calls to the web service will occur in a specific order. It sounds like you have an implicit sequence the data needs to arrive in the destination application, which makes me think you need to group your messages together and send them together to ensure that order.
No matter the speed of the messaging framework, you cannot guarantee to prevent a race condition that could send messages out of order, unless you send one message that has your data in the correct order.
If you are sending messages in a sequence across internet, you will never know how long will take the message to arrive from one point to another. One possible solution is to include in each message its position in the sequence, and in each endpoint implement the logic to order the messages prior to processing them. If you receive a message out of sequence, you can wait for the missing message, or request to the other endpoint to resend it.
Does anyone have experiance in a lot of these?
I'm not so intrested in the pdf creation part of LCDS.
Just for flex messaging which would give me the best performance? As far as I know LCDS and WebOrb both do real time streaming is that correct?
Basically the question is which gives quickest response and which will allow for most client connected to a single servlet container.
Thanks
Edit 1
This may be clearer what I want. I'm looking to server at least 5000 clients with sub second response times with push messages, I'm trying to figure out which is the most scalable option, I've been quoted several million push messages a day. Obviously we can throw more servers at the problem I'm not convinced thats the most maintainable option.
Its not media streaming I'm looking for, but more event updates. It must work without sticky sessions.
LiveCycleDS & WebOrb are the only ones providing messaging using sockets through RTMP protocol. Note that in this case the clients are not connected to a servlet container, but to a dedicated server included in the product distribution (bypassing the servlet mechanism).
There are more messaging servers on the market, Lightstreamer is one of them. Or Flash media server.
There are many more things to be taken into consideration when choosing a solution however (price, integration with various architectures (like DMZ) and frameworks, paid support, documentation, your relation with the sales representative etc).