About Zinc http components
Locked
12
12
 
|
Hi,
I played a bit with ZnServer and other zinc components and have a question I can't answer myself (googling a bit didn't help neither), and I'm seeking for advice: does it makes sense to use a ZnServer/ZnWebSocket as a mechanism to transfer data between two pharo processes - in my case 8k ByteArray blocks ? Or is it a total non sense ? is it reliable ? First tests looks good : 18k blocks / second (145 Mb/s) on a laptop core i5 2.6Ghz. All comments and suggestions welcome Thanks in advance, Alain |
Re: About Zinc http components
|
|
Hi Alain,
Any network protocol between two processes has overhead, even the one you would write yourself. It does make sense to use something that already exists, uses open standards and is used and battle tested by others. There is a fundamental difference between HTTP and WebSockets: HTTP is request/response where the initiative lies with the client, WebSockets is fully bidirectional once the connection is setup. There is also less overhead with WebSockets. In both cases you should take care to do your data conversions on/off the wire as efficient as possible. I would say: go for it. Sven On 07 Oct 2014, at 01:10, Alain Rastoul <[hidden email]> wrote: > Hi, > I played a bit with ZnServer and other zinc components and have > a question I can't answer myself (googling a bit didn't help neither), > and I'm seeking for advice: does it makes sense to use a ZnServer/ZnWebSocket > as a mechanism to transfer data between two pharo processes - in my case 8k ByteArray blocks ? > Or is it a total non sense ? is it reliable ? > First tests looks good : 18k blocks / second (145 Mb/s) on a laptop > core i5 2.6Ghz. > > All comments and suggestions welcome > > Thanks in advance, > > Alain |
Re: About Zinc http components
|
|
2014-10-07 4:59 GMT-03:00 Sven Van Caekenberghe <[hidden email]>:
> Hi Alain, > > Any network protocol between two processes has overhead, even the one you would write yourself. It does make sense to use something that already exists, uses open standards and is used and battle tested by others. > > There is a fundamental difference between HTTP and WebSockets: HTTP is request/response where the initiative lies with the client, WebSockets is fully bidirectional once the connection is setup. There is also less overhead with WebSockets. In both cases you should take care to do your data conversions on/off the wire as efficient as possible. > > I would say: go for it. +1 for each of the paragraphs. Plus in the not so far future HTTP2 [1] might be promoted to a standard, meanwhile SPDY [2] is already usable and deployed, so the connection cost and the protocol transport might become cheaper along faster underlying communication channels. Best regards! [1] https://tools.ietf.org/html/draft-ietf-httpbis-http2-14 [2] http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00 |
|
|
There are some good C libraries out there, which are suitable to
connect programs with each other: a good example is 0MQ. Marten -- Marten Feldtmann |
Re: About Zinc http components
|
|
Hi Marten, Is your 0mq library posted somewhere and MIT licensed? Thanks Paul |
Re: About Zinc http components
|
|
Thanks you for your answers.
0mq looks great, but released with LGPL licence, and I don't like that (I don't understand why there is also a GPL licence file in the distribution ? - clearly a *noway*), I prefer a full smalltalk implementation I can debug when things go wrong. I think latency and timing problems would be the same, no big difference in performance. BTW knowing about this library is cool and may be of some help (who knows), thank you Marten for the reference. I agree totally with you Sven about performance and standards. And I also agree with you about reusing someone else's work ... I don't like to reinvent the wheel, especially a good wheel when mine would be worst, I would if I were a wheel specialist - clearly not the case here. Much (if not all) of what I found on the web about WebSocket is about a browser/server connection and does not talk about use in a server/server connection, hence my question. But you answered it, and your answer is ok with my thoughts (plus using Zn components is a breeze) Thanks again regards, Alain Le 07/10/2014 18:26, Paul DeBruicker a écrit : > marten wrote >> There are some good C libraries out there, which are suitable to >> connect programs with each other: a good example is 0MQ. >> >> Marten >> >> -- >> Marten Feldtmann > > > Hi Marten, > > > Is your 0mq library posted somewhere and MIT licensed? > > Thanks > > Paul > > > > -- > View this message in context: http://forum.world.st/About-Zinc-http-components-tp4783071p4783223.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > |
|
|
I have a little different view. lpgl is no real problem for me - it may
be used for non-open-soure stuff without problems. Therefore I see no real problems with that. The other thing is: speed. And here it might differ a lot. I had written a heavy communication server in Smalltalk and with about 30 clients the Smalltalk process was CPU bound. No way to go. Introducing 0MQ and put all communication to an external thread and Smalltalk can fly again. That's the difference. Marten Am 07.10.2014 um 20:12 schrieb Alain Rastoul: > Thanks you for your answers. > > 0mq looks great, but released with LGPL licence, and I don't like that > (I don't > understand why there is also a GPL licence file in the distribution ? - > clearly a *noway*), > I prefer a full smalltalk implementation I can debug when things go wrong. > I think latency and timing problems would be the same, no big difference > in performance. > BTW knowing about this library is cool and may be of some help (who knows), > thank you Marten for the reference. > > I agree totally with you Sven about performance and standards. > And I also agree with you about reusing someone else's work ... > I don't like to reinvent the wheel, especially a good wheel when mine > would be worst, > I would if I were a wheel specialist - clearly not the case here. -- Marten Feldtmann |
Re: About Zinc http components
|
|
Marten,
I keep a close eye to MQ based architectures, because somehow they feel "the best way" to implement interprocess/service messaging. And also because I always wanted to implement something based on message queues, just for the sake of it. :) However I don't find them suitable for interactive bidirectional communication, but instead as their name suggest, queues. Ideally for asynchronous communication, a "fire and forget" way of messaging. If you go by the MQ path Sven implemented STAMP [1], which can work with RabbitMQ's adapter [2] Unless you have an evented/callback based subscription to a queue, the polling and message consumption from the queue itself will consume about similar CPU cycles. What you gain using MQ is that you can offload computation to other "worker images". Regards! [1] https://github.com/svenvc/docs/blob/master/neo/stamp.md [2] http://www.rabbitmq.com/stomp.html Esteban A. Maringolo 2014-10-07 15:18 GMT-03:00 [hidden email] <[hidden email]>: > I have a little different view. lpgl is no real problem for me - it may > be used for non-open-soure stuff without problems. Therefore I see no > real problems with that. > > The other thing is: speed. And here it might differ a lot. I had written > a heavy communication server in Smalltalk and with about 30 clients the > Smalltalk process was CPU bound. No way to go. > > Introducing 0MQ and put all communication to an external thread and > Smalltalk can fly again. That's the difference. > > Marten > > Am 07.10.2014 um 20:12 schrieb Alain Rastoul: >> Thanks you for your answers. >> >> 0mq looks great, but released with LGPL licence, and I don't like that >> (I don't >> understand why there is also a GPL licence file in the distribution ? - >> clearly a *noway*), >> I prefer a full smalltalk implementation I can debug when things go wrong. >> I think latency and timing problems would be the same, no big difference >> in performance. >> BTW knowing about this library is cool and may be of some help (who knows), >> thank you Marten for the reference. >> >> I agree totally with you Sven about performance and standards. >> And I also agree with you about reusing someone else's work ... >> I don't like to reinvent the wheel, especially a good wheel when mine >> would be worst, >> I would if I were a wheel specialist - clearly not the case here. > > > -- > Marten Feldtmann > |
|
In reply to this post by Alain Rastoul-2
there is nanomsg which is a rethinking on 0mq and from same developers, its MIT licensed --> http://nanomsg.org/index.html On Tue, Oct 7, 2014 at 9:12 PM, Alain Rastoul <[hidden email]> wrote: Thanks you for your answers. |
|
|
In reply to this post by Esteban A. Maringolo
Esteban,
die mq in 0mq is misleading here because it is not a message queue. 0mq is called sockets on stereoids where you can plug communication channels with less overhead. It is more of an orchestration toolkit for distributed computing. Norbert > Am 07.10.2014 um 20:54 schrieb Esteban A. Maringolo <[hidden email]>: > > Marten, > > I keep a close eye to MQ based architectures, because somehow they > feel "the best way" to implement interprocess/service messaging. And > also because I always wanted to implement something based on message > queues, just for the sake of it. :) > > However I don't find them suitable for interactive bidirectional > communication, but instead as their name suggest, queues. Ideally for > asynchronous communication, a "fire and forget" way of messaging. > If you go by the MQ path Sven implemented STAMP [1], which can work > with RabbitMQ's adapter [2] > > Unless you have an evented/callback based subscription to a queue, the > polling and message consumption from the queue itself will consume > about similar CPU cycles. What you gain using MQ is that you can > offload computation to other "worker images". > > Regards! > > > [1] https://github.com/svenvc/docs/blob/master/neo/stamp.md > [2] http://www.rabbitmq.com/stomp.html > Esteban A. Maringolo > > > 2014-10-07 15:18 GMT-03:00 [hidden email] <[hidden email]>: >> I have a little different view. lpgl is no real problem for me - it may >> be used for non-open-soure stuff without problems. Therefore I see no >> real problems with that. >> >> The other thing is: speed. And here it might differ a lot. I had written >> a heavy communication server in Smalltalk and with about 30 clients the >> Smalltalk process was CPU bound. No way to go. >> >> Introducing 0MQ and put all communication to an external thread and >> Smalltalk can fly again. That's the difference. >> >> Marten >> >> Am 07.10.2014 um 20:12 schrieb Alain Rastoul: >>> Thanks you for your answers. >>> >>> 0mq looks great, but released with LGPL licence, and I don't like that >>> (I don't >>> understand why there is also a GPL licence file in the distribution ? - >>> clearly a *noway*), >>> I prefer a full smalltalk implementation I can debug when things go wrong. >>> I think latency and timing problems would be the same, no big difference >>> in performance. >>> BTW knowing about this library is cool and may be of some help (who knows), >>> thank you Marten for the reference. >>> >>> I agree totally with you Sven about performance and standards. >>> And I also agree with you about reusing someone else's work ... >>> I don't like to reinvent the wheel, especially a good wheel when mine >>> would be worst, >>> I would if I were a wheel specialist - clearly not the case here. >> >> >> -- >> Marten Feldtmann >> > |
|
|
In reply to this post by Esteban A. Maringolo
0MQ is not message queueing in the normal sense as known from all other
MQ tools/libraries. 0MQ is about networking in general ... and their introduction text with all their examples is one of the best examples documentation I've ever read in the area of practical networking. Even though one might not use 0MQ one should read their views about putting network patterns together to form a distributed network of software nodes (in different languages). For Smalltalk 0MQ is a wonderful library: -> because of the interactive character of Smalltalk you might run a 0MQ node and still can inspect the whole traffic. That's a thing other languages can dream of. -> due to the fact, that the whole communcation is done in an external thread you simply win Smalltalk CPU time (which is always needed). Marten |
Re: About Zinc http components
|
|
In reply to this post by Alain Rastoul-2
Hi. Why not use some kind of remote smalltalk like http://www.squeaksource.com/rST.html? 2014-10-07 3:10 GMT+04:00 Alain Rastoul <[hidden email]>: Hi, |
Re: About Zinc http components
|
|
In reply to this post by NorbertHartl
2014-10-07 16:19 GMT-03:00 Norbert Hartl <[hidden email]>:
> Esteban, > > die mq in 0mq is misleading here because it is not a message queue. 0mq is called sockets on stereoids where you can plug communication channels with less overhead. It is more of an orchestration toolkit for distributed computing. I can see. Thank you. I overlooked it, It seems really cool! But certainly it is more low level than a "regular" MQ :) Regards! |
|
|
In reply to this post by Alain Rastoul-2
Typical issue in the EJB world : Remote Beans / Local Beans , though on inter process it was remote beans with its full stack RMI marshalling / unmarshalling. But can we not exploit shared memory and efficient Event mechanism to make the two process coordinate, that should be lot more efficient than TCP - IP / but if that performance suffices it would be fine.. On Tue, Oct 7, 2014 at 4:40 AM, Alain Rastoul <[hidden email]> wrote: Hi, |
Re: About Zinc http components
|
|
In reply to this post by marten
About 0mq, to be honest, I missed the external thread part,
and that's *very* interesting , for sure. I find the license part quite complicated, but rereading it, you are right, it should not be a problem (though still weird). My goal is not to build a server with a lot of connections, and no message queuing neither, but (for this part) a server with some basic and raw "streaming" functionality and quite few connections for a start - this functionality is not the core of the system, just a part of it, and I'm trying to find building blocks. I think I have to make some compatible api on top of whatever I choose (ZnWebSockets/0mq or nanomsg) to be able to change easily. Do you know some existing good bindings for this library that I could reuse? The one on gemstone/squeaksource3 (from you?) seems to be empty, one on smalltalkhub (panuw) that I was able to load correctly and was maintained until february 2014. Thanks Alain Le 07/10/2014 21:23, [hidden email] a écrit : > 0MQ is not message queueing in the normal sense as known from all other > MQ tools/libraries. > > 0MQ is about networking in general ... and their introduction text with > all their examples is one of the best examples documentation I've ever > read in the area of practical networking. Even though one might not use > 0MQ one should read their views about putting network patterns together > to form a distributed network of software nodes (in different languages). > > For Smalltalk 0MQ is a wonderful library: > > -> because of the interactive character of Smalltalk you might run a 0MQ > node and still can inspect the whole traffic. That's a thing other > languages can dream of. > > -> due to the fact, that the whole communcation is done in an external > thread you simply win Smalltalk CPU time (which is always needed). > > > Marten > > |
Re: About Zinc http components
|
|
In reply to this post by kilon.alios
Nanosg looks interesting too, thank you Kilon, I will look at it closer too.
Do you known some working bindings with pharo ? Alain Le 07/10/2014 21:12, kilon alios a écrit : > there is nanomsg which is a rethinking on 0mq and from same developers, > its MIT licensed --> http://nanomsg.org/index.html > > On Tue, Oct 7, 2014 at 9:12 PM, Alain Rastoul > <[hidden email] > <mailto:[hidden email]>> wrote: > > Thanks you for your answers. > > 0mq looks great, but released with LGPL licence, and I don't like > that (I don't > understand why there is also a GPL licence file in the distribution > ? - clearly a *noway*), > I prefer a full smalltalk implementation I can debug when things go > wrong. > I think latency and timing problems would be the same, no big > difference in performance. > BTW knowing about this library is cool and may be of some help (who > knows), > thank you Marten for the reference. > > I agree totally with you Sven about performance and standards. > And I also agree with you about reusing someone else's work ... > I don't like to reinvent the wheel, especially a good wheel when > mine would be worst, > I would if I were a wheel specialist - clearly not the case here. > > Much (if not all) of what I found on the web about WebSocket is > about a browser/server connection > and does not talk about use in a server/server connection, hence my > question. > But you answered it, and your answer is ok with my thoughts > (plus using Zn components is a breeze) > > Thanks again > > regards, > > Alain > Le 07/10/2014 18:26, Paul DeBruicker a écrit : > > marten wrote > > There are some good C libraries out there, which are suitable to > connect programs with each other: a good example is 0MQ. > > Marten > > -- > Marten Feldtmann > > > > Hi Marten, > > > Is your 0mq library posted somewhere and MIT licensed? > > Thanks > > Paul > > > > -- > View this message in context: > http://forum.world.st/About-__Zinc-http-components-__tp4783071p4783223.html > <http://forum.world.st/About-Zinc-http-components-tp4783071p4783223.html> > Sent from the Pharo Smalltalk Users mailing list archive at > Nabble.com. > > > > > > |
Re: About Zinc http components
|
|
In reply to this post by S Krish
This is another subject and another functionality I will need too.
The Rst link is of interest (thank you Denis) , I was thinking of sending command objects with Fuel as all images will have the same classes and performance is not very important here. I was able to load RST in Pharo3, but did not made any test yet. Does it works with Pharo ? @SKrish you are right, but I want to keep as simple as possible at the beginning and tcpip should fit for a start. Cheers, Alain Le 07/10/2014 21:40, S Krish a écrit : > > Typical issue in the EJB world : Remote Beans / Local Beans , though on > inter process it was remote beans with its full stack RMI marshalling / > unmarshalling. > > But can we not exploit shared memory and efficient Event mechanism to > make the two process coordinate, that should be lot more efficient than > TCP - IP / but if that performance suffices it would be fine.. > > > > > On Tue, Oct 7, 2014 at 4:40 AM, Alain Rastoul > <[hidden email] > <mailto:[hidden email]>> wrote: > > Hi, > I played a bit with ZnServer and other zinc components and have > a question I can't answer myself (googling a bit didn't help neither), > and I'm seeking for advice: does it makes sense to use a > ZnServer/ZnWebSocket > as a mechanism to transfer data between two pharo processes - in my > case 8k ByteArray blocks ? > Or is it a total non sense ? is it reliable ? > First tests looks good : 18k blocks / second (145 Mb/s) on a laptop > core i5 2.6Ghz. > > All comments and suggestions welcome > > Thanks in advance, > > Alain > > > |
|
|
In reply to this post by Alain Rastoul-2
nope but it is made (unlike 0mq which is made in C++) in C so its should be relative simple to wrap with NB or even TalkFFI. At least the parts that interest you. On Tue, Oct 7, 2014 at 11:56 PM, Alain Rastoul <[hidden email]> wrote: Nanosg looks interesting too, thank you Kilon, I will look at it closer too. |
Re: About Zinc http components
|
|
In reply to this post by Alain Rastoul-2
I was try it many years ago with squeak. It was work great. I am sure it should be not difficult to adobt it for latest pharo 08 окт. 2014 г. 1:09 пользователь "Alain Rastoul" <[hidden email]> написал:
This is another subject and another functionality I will need too. |
|
|
In reply to this post by kilon.alios
0MQ is defined by its exported C interface ...
Am 07.10.2014 um 23:51 schrieb kilon alios: > nope but it is made (unlike 0mq which is made in C++) in C so its > should be relative simple to wrap with NB or even TalkFFI. At least the > parts that interest you. > -- Marten Feldtmann |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |