- Pharo-users - lists.pharo.org

Re: [Pharo-users] About Zinc http components

by itlists＠schrievkrom.de

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

Oct. 8, 2014

Re: [Pharo-users] About Zinc http components

by Denis Kudriashov

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" <alf.mmm.cat(a)gmail.com> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: > 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 >> <alf.mmm.cat(a)gmail.com >> <mailto:alf.mmm.cat@gmail.com>> 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 >> >> >> >> > > >

Oct. 8, 2014

Re: [Pharo-users] About Zinc http components

by 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. On Tue, Oct 7, 2014 at 11:56 PM, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > 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 >> <alf.mmm.cat(a)gmail.com >> <mailto:alf.mmm.cat@gmail.com>> 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. >> >> >> >> >> >> >> > > >

Oct. 7, 2014

Re: [Pharo-users] About Zinc http components

by Alain Rastoul

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 > <alf.mmm.cat(a)gmail.com > <mailto:alf.mmm.cat@gmail.com>> 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 > > >

Oct. 7, 2014

Re: [Pharo-users] About Zinc http components

by Alain Rastoul

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 > <alf.mmm.cat(a)gmail.com > <mailto:alf.mmm.cat@gmail.com>> 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. > > > > > >

Oct. 7, 2014

Re: [Pharo-users] About Zinc http components

by Alain Rastoul

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, itlists(a)schrievkrom.de 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 > >

Oct. 7, 2014

Re: [Pharo-users] About Zinc http components

by S Krish

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 <alf.mmm.cat(a)gmail.com> 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 > > >

Oct. 7, 2014

Re: [Pharo-users] About Zinc http components

by Esteban A. Maringolo

2014-10-07 16:19 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: > 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!

Oct. 7, 2014

Re: [Pharo-users] About Zinc http components

by Denis Kudriashov

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 <alf.mmm.cat(a)gmail.com>: > 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 > > >

Oct. 7, 2014

Re: [Pharo-users] About Zinc http components

by itlists＠schrievkrom.de

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

Oct. 7, 2014