> On 19 Nov 2014, at 20:52, Esteban A. Maringolo <emaring...@gmail.com> wrote: > > My current use case is pretty simple, being able to push requests to the > remote devices, and gather the data back, assuming the remote devices > (clients) are already connected to the server, which is a client-related > problem with any messaging solution. > > I learn about MQTT when looking for alternatives to Google Cloud Messaging > for Android (which is built on to of XMPP). Facebook Messenger uses MQTT. > > I don't want to develop an overkill solution that could delay deliverance of > value to my customer, though I find implementing an MQ/MQTT solution > intellectually challenging. I even read the standard a few months ago, and it > seems to be simpler than expected. I'd love to go down the "implement MQTT > server in Pharo", I would lose a real MQ scalability, but it could be a good > way to learn the protocol, and an alternative to Mosquitto [1] with the > benefits of having a server inside the image. > > Do you have experience with the scalability of Zinc WebSockets? > How many of them can a single Pharo image handle? The I/O would be minimal (< > 1KB) per message, and the requests would be measured in minutes instead of > seconds. Although a 50 ws frames/sec peak during a couple of seconds is > feasible.
I don't have any production level experience with (Zinc) WebSockets. But we have some Pharo images in production doing related things. Based on that I would say 100s of concurrent open connections is doable, but I would be careful if you know you will scale to 1000s. Why ? Because each connection is a socket(stream) with 3 semaphores and a process/thread. It will still work, but it might be harder to keep things together. BTW, this is not a Pharo problem per se, it will be hard(er) everywhere. I just read that MQTT over WebSockets also exists ;-) I guess that you have no RabbitMQ experience so maybe that scares you a bit, you will have to learn some new things, but it is not hard (and it is quite interesting). In terms of doing MQTT directly in Pharo, I would start with the client side, it can't be very hard to do (there are many clients already). > Regards, > > [1] http://mosquitto.org/ > > El Wed Nov 19 2014 at 4:22:56 PM, Sven Van Caekenberghe <s...@stfx.eu> > escribió: > Hey Esteban, > > Since you seem to need to scale to 1000s of concurrent connections, I would > go for option 2. RabbitMQ will then work as a demultiplexer and you gain > options for using more than one Pharo worker for processing traffic, if that > ever becomes necessary. > > BTW, I never heard of MQTT and it seems pretty interesting, thanks ! I will > read about it tonight. > > Sven > > > On 19 Nov 2014, at 19:06, Esteban A. Maringolo <emaring...@gmail.com> wrote: > > > > Hi, > > > > I'll be needing to add bidirectional messaging to our current Android > > (Java) application, and as usual I'm expecting to manage the server side of > > the communication with Pharo. > > > > I'm evaluating two alternatives, but I'm in open to other, proven, options. > > > > Option 1. WebSockets > > Open a WebSocket on each device, and push/retrieve messages from each of > > these, tracking the device id if I need to recreate a new socket (avoiding > > recreating new sockets in case of connectivity issues, very common). > > > > Option 2. MQTT [1] > > This is basically a mobile oriented MQ, super low footprint on mobile. > > For what I saw, I could implement the server using an intermediate MQ > > (RabbitMQ) and use STOMP to connect to it. > > > > Option 3. XMPP [3] > > Provides several features I'll need in the future, like file transfer in > > addition to regular text messaging. It is very well supported in Android > > with Smack [4], but I don't know if we have a Pharo server for it, or if > > somebody ever played with it. > > > > By means of simplicity and use load I favor option 1, because I can > > understand it better, and as everything moves towards web based > > technologies, I could implement WAMP [5] on top of that in the future. > > > > Right now I'd need to have a hundred websockets opened at the same time, > > which doesn't sound like a heavy load to me, but I certainly don't know. In > > the future it could be an order of magnitude bigger, and that's why I don't > > discard more complex solutions like XMPP or MQTT. > > > > Regards! > > > > > > [1] http://mqtt.org/ > > [2] https://github.com/svenvc/docs/blob/master/neo/stamp.md > > [3] http://xmpp.org/ > > [4] http://www.igniterealtime.org/projects/smack/ > > [5] http://wamp.ws/ > > > > > >
