Messaging solutions for Pharo

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Messaging solutions for Pharo

Esteban A. Maringolo
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!




Reply | Threaded
Open this post in threaded view
|

Re: Messaging solutions for Pharo

Andres Fortier-3
Hi Esteban,
Never used either of them, but IIRC there was a Jabber package in Visualworks (JabberXMPP?), although not sure if it provided both client and server. There is also http://www.squeaksource.com/@zQrCJXpxIQLxqde8/tV369AO0. Seems dated, but maybe worth a shot considering you only need the server side?

HTH,
Andrés

On Wed, Nov 19, 2014 at 3:06 PM, Esteban A. Maringolo <[hidden email]> 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!





Reply | Threaded
Open this post in threaded view
|

Re: Messaging solutions for Pharo

Sven Van Caekenberghe-2
In reply to this post by Esteban A. Maringolo
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 <[hidden email]> 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/
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Messaging solutions for Pharo

Esteban A. Maringolo
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.

Regards,

[1] http://mosquitto.org/

El Wed Nov 19 2014 at 4:22:56 PM, Sven Van Caekenberghe <[hidden email]> 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 <[hidden email]> 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/
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Messaging solutions for Pharo

Sven Van Caekenberghe-2

> On 19 Nov 2014, at 20:52, Esteban A. Maringolo <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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/
> >
> >
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Messaging solutions for Pharo

Brian Brown

I've used XMPP extensively for several projects, from python, JavaScript, and Squeak - the wonderful thing about it is that you can start off simple using just chat messages, but then add more features like pub sub, conference rooms, service discovery, etc. Scalability is built into the system, and you start out with Prosody jabber server (easy to get going, written in Lua).

There are a lot of good books on the protocol and its supported by most environments you can think of...

Now for the "bad" news. The library I used in smalltalk was written by Michael Rueger, and I don't think it has been updated for years; I think there is a version on squeaksource, so it would have to be brought up to current state of XML libs and so forth.

Anyway, I like XMPP ;-)

- Brian

On Nov 19, 2014 1:29 PM, "Sven Van Caekenberghe" <[hidden email]> wrote:

> On 19 Nov 2014, at 20:52, Esteban A. Maringolo <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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/
> >
> >
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Messaging solutions for Pharo

stepharo
In reply to this post by Andres Fortier-3
Hello Andres

nice to see you on this list :)

Stef

Le 19/11/14 19:40, Andres Fortier a écrit :
Hi Esteban,
Never used either of them, but IIRC there was a Jabber package in Visualworks (JabberXMPP?), although not sure if it provided both client and server. There is also http://www.squeaksource.com/@zQrCJXpxIQLxqde8/tV369AO0. Seems dated, but maybe worth a shot considering you only need the server side?

HTH,
Andrés

On Wed, Nov 19, 2014 at 3:06 PM, Esteban A. Maringolo <[hidden email]> 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!






Reply | Threaded
Open this post in threaded view
|

Re: Messaging solutions for Pharo

Andres Fortier-3
Hi Stef,

thanks! Glad to be doing things in Pharo :)

On Sun, Nov 23, 2014 at 9:24 AM, stepharo <[hidden email]> wrote:
Hello Andres

nice to see you on this list :)

Stef

Le 19/11/14 19:40, Andres Fortier a écrit :
Hi Esteban,
Never used either of them, but IIRC there was a Jabber package in Visualworks (JabberXMPP?), although not sure if it provided both client and server. There is also http://www.squeaksource.com/@zQrCJXpxIQLxqde8/tV369AO0. Seems dated, but maybe worth a shot considering you only need the server side?

HTH,
Andrés

On Wed, Nov 19, 2014 at 3:06 PM, Esteban A. Maringolo <[hidden email]> 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!







Reply | Threaded
Open this post in threaded view
|

Re: Messaging solutions for Pharo

Bernat Romagosa
Hi Esteban,

did you finally choose MQTT? I'm in the beginning of a project right now where we need to communicate with a bunch of devices and we've considered MQTT, but we don't know whether to use some existing broker like mosquitto or implement it in Pharo. Have you been down this path?

Thanks!
Bernat.

2014-11-24 11:55 GMT+01:00 Andres Fortier <[hidden email]>:
Hi Stef,

thanks! Glad to be doing things in Pharo :)

On Sun, Nov 23, 2014 at 9:24 AM, stepharo <[hidden email]> wrote:
Hello Andres

nice to see you on this list :)

Stef

Le 19/11/14 19:40, Andres Fortier a écrit :
Hi Esteban,
Never used either of them, but IIRC there was a Jabber package in Visualworks (JabberXMPP?), although not sure if it provided both client and server. There is also http://www.squeaksource.com/@zQrCJXpxIQLxqde8/tV369AO0. Seems dated, but maybe worth a shot considering you only need the server side?

HTH,
Andrés

On Wed, Nov 19, 2014 at 3:06 PM, Esteban A. Maringolo <[hidden email]> 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!










--
Bernat Romagosa.
Reply | Threaded
Open this post in threaded view
|

Re: Messaging solutions for Pharo

Esteban A. Maringolo
Hi Bernat,

I did some with MQTT in Java/Android and JavaScript with Paho, but
never used it with Pharo nor in any of our products.

Regards!
Esteban A. Maringolo


2015-04-08 10:55 GMT-03:00 Bernat Romagosa <[hidden email]>:

> Hi Esteban,
>
> did you finally choose MQTT? I'm in the beginning of a project right now
> where we need to communicate with a bunch of devices and we've considered
> MQTT, but we don't know whether to use some existing broker like mosquitto
> or implement it in Pharo. Have you been down this path?
>
> Thanks!
> Bernat.
>
> 2014-11-24 11:55 GMT+01:00 Andres Fortier <[hidden email]>:
>>
>> Hi Stef,
>>
>> thanks! Glad to be doing things in Pharo :)
>>
>> On Sun, Nov 23, 2014 at 9:24 AM, stepharo <[hidden email]> wrote:
>>>
>>> Hello Andres
>>>
>>> nice to see you on this list :)
>>>
>>> Stef
>>>
>>> Le 19/11/14 19:40, Andres Fortier a écrit :
>>>
>>> Hi Esteban,
>>> Never used either of them, but IIRC there was a Jabber package in
>>> Visualworks (JabberXMPP?), although not sure if it provided both client and
>>> server. There is also
>>> http://www.squeaksource.com/@zQrCJXpxIQLxqde8/tV369AO0. Seems dated, but
>>> maybe worth a shot considering you only need the server side?
>>>
>>> HTH,
>>> Andrés
>>>
>>> On Wed, Nov 19, 2014 at 3:06 PM, Esteban A. Maringolo
>>> <[hidden email]> 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/
>>>>
>>>>
>>>
>>>
>>
>
>
>
> --
> Bernat Romagosa.

Reply | Threaded
Open this post in threaded view
|

Re: Messaging solutions for Pharo

Bernat Romagosa
Thanks! I guess I'll use mosquitto as a middleware then, and Zinc/Websockets from Pharo.

Best,
Bernat.

2015-04-08 16:47 GMT+02:00 Esteban A. Maringolo <[hidden email]>:
Hi Bernat,

I did some with MQTT in Java/Android and JavaScript with Paho, but
never used it with Pharo nor in any of our products.

Regards!
Esteban A. Maringolo


2015-04-08 10:55 GMT-03:00 Bernat Romagosa <[hidden email]>:
> Hi Esteban,
>
> did you finally choose MQTT? I'm in the beginning of a project right now
> where we need to communicate with a bunch of devices and we've considered
> MQTT, but we don't know whether to use some existing broker like mosquitto
> or implement it in Pharo. Have you been down this path?
>
> Thanks!
> Bernat.
>
> 2014-11-24 11:55 GMT+01:00 Andres Fortier <[hidden email]>:
>>
>> Hi Stef,
>>
>> thanks! Glad to be doing things in Pharo :)
>>
>> On Sun, Nov 23, 2014 at 9:24 AM, stepharo <[hidden email]> wrote:
>>>
>>> Hello Andres
>>>
>>> nice to see you on this list :)
>>>
>>> Stef
>>>
>>> Le 19/11/14 19:40, Andres Fortier a écrit :
>>>
>>> Hi Esteban,
>>> Never used either of them, but IIRC there was a Jabber package in
>>> Visualworks (JabberXMPP?), although not sure if it provided both client and
>>> server. There is also
>>> http://www.squeaksource.com/@zQrCJXpxIQLxqde8/tV369AO0. Seems dated, but
>>> maybe worth a shot considering you only need the server side?
>>>
>>> HTH,
>>> Andrés
>>>
>>> On Wed, Nov 19, 2014 at 3:06 PM, Esteban A. Maringolo
>>> <[hidden email]> 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/
>>>>
>>>>
>>>
>>>
>>
>
>
>
> --
> Bernat Romagosa.




--
Bernat Romagosa.