Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

LDC goes Rugby!

 [1/32] from: m:koopmans2:chello:nl at: 21-May-2001 18:40


Hi List, You can find a script called rugby.r in the script lib / LDC on the view desktop. Rugby is a framework for exposing top level functions to other Rebol processes. It runs on top of 2.5, view and Command 2 Rugby sports sandboxing (limited execution), message integrity and async I/O for performance. It is used in a large scale commercial project as middleware for a crypto-server. LDC at its best.... after doing years of CORBA, DCOm amd RMI and with SOAP and .NOT on the horizon you finally have distributed computing the way it is meant to be: transparent.... So now we have: -Middleware -Server page technology (erebol) -MySQL integration with the native libs and as a Rebol protocol. Sounds like a maturing platform :) See the test functions at the end of rugby.r A sample: echo: func [ e ] [ return mold e] rugby-server/init-server make port! tcp://:8001 [echo] rugby-server/go starts a rugby server that expose only the echo function from another rebol process type rugby-client/rexec [echo "Howdy"] Enjoy! --Maarten

 [2/32] from: gjones05:mail:orion at: 22-May-2001 12:13


From: "Maarten Koopmans"
<snip>

 [3/32] from: gjones05:mail:orion at: 22-May-2001 12:32


Sorry about the empty reply message. Slip of the fingers sent off the message before I finished. I was having trouble getting the client to run, when I realized it was merely a formatting problem in my local copy of rugby.r file. Running great locally. Way to go, Maarten! --Scott Jones

 [4/32] from: m:koopmans2:chello:nl at: 22-May-2001 20:45


Thanks Scott. I am surprised you are the only one that responded though. Now I'll add /Pro based encryption and there you go... --Maarten

 [5/32] from: doug:vos:eds at: 22-May-2001 15:32


What's the link to RUGBY.r ??

 [6/32] from: petr:krenzelok:trz:cz at: 22-May-2001 21:49


----- Original Message ----- From: "Maarten Koopmans" <[m--koopmans2--chello--nl]> To: <[rebol-list--rebol--com]> Sent: Tuesday, May 22, 2001 8:45 PM Subject: [REBOL] Re: LDC goes Rugby!
> Thanks Scott. > > I am surprised you are the only one that responded though. Now I'll add
/Pro
> based encryption and there you go...
I saw it already yesterday and mentioned it to Carl, and today to the list. I have printed the source code to study and I can find it pretty cool. One thing to consider: maybe you could check/checksum the functions as being the same? e.g. function called 'x on server doesn't necessarily have to be the same as 'x on the client side? I was already thinking of similar aproach, where client and server would (just after the connection) exchange some kind of set-up info (object), describing protocol name, protocol version, protocol compatibility version, compression, encryption usage etc., and would be possible to exchange dialects some way. Dialect based protocols could be cool. Imagine some special purpose server - all you need is just domain based dialect ... but maybe my thoughts here are not practical or applicable in any sense, as noone replied to thoughts :-) But imo /Express uses dialect for synchronisation purposes and there was also some link to article describing semantic web or something similar (haven't read it though :-) However - keep up the good work! -pekr-

 [7/32] from: petr:krenzelok:trz:cz at: 22-May-2001 21:57


----- Original Message ----- From: "Vos, Doug" <[doug--vos--eds--com]> To: <[rebol-list--rebol--com]> Sent: Tuesday, May 22, 2001 9:32 PM Subject: [REBOL] Re: LDC goes Rugby!
> What's the link to RUGBY.r ??
Don't know exactly now, but try to go to View desktop, library section, tcp section, and you will see it ... -pekr-

 [8/32] from: ryanc:iesco-dms at: 22-May-2001 12:58


I have a script that I am polishing, that is similar, but more of a virtual machine. Everything is exported on the server. It works right now, but I want to make it so you can send it a process and forget about it until its done. --Ryan Petr Krenzelok wrote:
> ----- Original Message ----- > From: "Maarten Koopmans" <[m--koopmans2--chello--nl]>
<<quoted lines omitted: 54>>
> [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes.
-- Ryan Cole Programmer Analyst www.iesco-dms.com 707-468-5400 I am enough of an artist to draw freely upon my imagination. Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -Einstein

 [9/32] from: doug:vos:eds at: 22-May-2001 16:07


Need a real URL link with fully qualified name. Not everyone is using the View desktop. We use REBOL/Command only (at this time).

 [10/32] from: alan_otterstad:mikronvinyl at: 22-May-2001 13:22


Try http://www.reboltech.com/library/scripts/rugby.r

 [11/32] from: gjones05:mail:orion at: 22-May-2001 15:37


From: "Vos, Doug"
> Need a real URL link with fully qualified name. > Not everyone is using the View desktop. > We use REBOL/Command only (at this time). >
http://www.reboltech.com/library/scripts/rugby.r

 [12/32] from: gjones05:mail:orion at: 22-May-2001 16:15


> From: "GS Jones" <snip> >> Running great locally. Way to go, Maarten! >> --Scott Jones
From: "Maarten Koopmans"
> Thanks Scott. > > I am surprised you are the only one that responded though. Now I'll
add /Pro
> based encryption and there you go... > > --Maarten
The more I've thought about your model, the more I realize that this is world class stuff. Instead of making simple things simple, your framework makes a very, very difficult thing very, very simple ... even for me! :-) I think that two things have conspired to surpress the response. First, the list has been, shall we say, distracted? I know I was. I'm normally a careful reader and I somehow glossed right over this entry. I remember reading it; it just didn't sink in. (My subconscious mind was probably focused more on the name --- I guess I wasn't interested in playing rugby yesterday. The name is actually very appropriate, so certainly don't change it!) The second thing is what I ran into. I just reposted the precise, fully-qualified URL for Doug. Out of curiosity, I re-downloaded it directly. The formatting problem I experienced remains. The line following ;now try to read the rest of the message is split. And the line beginning server-test: does needs the block to start on the same line. Those two things fix it. After correction and the addition of encryption, I would reannounce your solution framework after things die down a bit. Thanks again for the contribution. --Scott Jones

 [13/32] from: brett:codeconscious at: 23-May-2001 11:31


> dialects some way. Dialect based protocols could be cool. Imagine some > special purpose server - all you need is just domain based dialect ... but > maybe my thoughts here are not practical or applicable in any sense, as > noone replied to thoughts :-)
Hah. :) Your message in a bottle did get received and BTW Maarten's did too - just going to take a little while to analyse it - boy he crammed a bit into that bottle :) Dialects are definitely practical and applicable but they represent a way of looking at things that is different to the way many of us may have trained our brains. Training one's brain is hard but as my first attempt the following is how I look at dialects in general. Dialect = Protocol Dialect = API Dialect = Instructions Dialect = Linearised object model In others words dialects abound already - but these are meant for lower-level interpreters ;-) The new thing is that we have been given the capability to make our own dialects in a simple fashion. So the trick is to get people (me included) thinking how simple and expressive a new dialect can be. A bit of training too in how to design the the grammars and interpreters would be useful too. I realise there are already examples but I reckon this topic is lead by the nose-ring stuff. In other words the Library needs a Dialect folder too. Or if one wants to be bold a whole new site - because dialects are a worthwhile even if one hasn't got the tools (Rebol Parse) to make them easy to deal with. Brett.

 [14/32] from: petr:krenzelok:trz:cz at: 23-May-2001 8:00


Brett Handley wrote:
> > dialects some way. Dialect based protocols could be cool. Imagine some > > special purpose server - all you need is just domain based dialect ... but
<<quoted lines omitted: 21>>
> bold a whole new site - because dialects are a worthwhile even if one hasn't > got the tools (Rebol Parse) to make them easy to deal with.
I thought of mechanism, which I am not sure would be efficient, but maybe Holger could respond here :-) - main task (e.g. rugby server) - accepting connections (e.g. FastCGI) - there would be defined max. number of simultaneous (handled by 1 instance of rebol) connections somewhere in config (and maybe could be changed accordingly during run time too) - once max number of simultaneous connections is reached: a) other copy of LOCAL Rebol could be 'launched, connected to master by TCP port Q: does the solution scale well? We currently have Sterling's proxy script or Rugby available e.g., which show us we can handle connections by parts, so it feels like "multitasking". But there is probably some limit to rebol speed, where timeouts will get longer. So - will launching new OS task (new Rebol instance, connected to "master" task, performing the same kind of functionality) help to locally load balance connections handling? b) there could be REMOTE instance of Rebol running, so task distribution could be done thru several machines. So: top-master ---------------------------------- | | .... | | local1 local2 localx | master1 ------------------ | local1 .... etc. Other two question related to ports: - I noticed that Maarten used open/direct non buffered aproach? Does it have any advantage upon using buffered ports, e.g. "blocking" issues? - I also noticed following piece of code. What does it do exactly, please - I mean how does it influence port? set-modes conn [ async-modes: [read write]] Thanks, -pekr-

 [15/32] from: m:koopmans2:chello:nl at: 23-May-2001 11:08


Doug, Rugby utilizes async I/O and will only work with View/Pro, Core 2.5 and the upcoming Command 2.0 --Maarten

 [16/32] from: petr:krenzelok:trz:cz at: 23-May-2001 11:23


Maarten Koopmans wrote:
> Doug, > > Rugby utilizes async I/O and will only work with View/Pro, Core 2.5 and the > upcoming Command 2.0
I already asked in another email, but - a) It works imo under View too ... not only View/Pro b) what is difference in using async I/O? I mean - in what way it affects functionality? Thanks, -pekr-

 [17/32] from: m:koopmans2:chello:nl at: 23-May-2001 12:08


Pekr, It works under View as well, you are right. Async I/O adds non-blocking behaviour. If you accept a port on the server side, you can do two things: 1) Try to read data and continue once you get it all. This way you essentially block all other activity. If the line happens to be slow, too bad for the rest ofthe connections. they have to wait. 2) If there is data availaible, you take what you can get. If you try to read more than there is available, you don't wait. In stead, an error isthrown (that you catch) and you continue immediately. And you don't spend waiting time and slowing down other connections. Note that point 2 is more work though (right now). Holger said that no other app except for Serve should use async I/O until they finalize the APIs in core 3.0 That said, They didn't help me finding this out either (one guy from the mailing list did very briefly). --Maarten

 [18/32] from: petr:krenzelok:trz:cz at: 23-May-2001 12:38


Maarten Koopmans wrote:
> Pekr, > It works under View as well, you are right.
<<quoted lines omitted: 3>>
> essentially block all other activity. If the line happens to be slow, too > bad for the rest ofthe connections. they have to wait.
doesn't it depend upon /no-wait 'open refinement?
> 2) If there is data availaible, you take what you can get. If you try to > read more than there is available, you don't wait. In stead, an error > isthrown (that you catch) and you continue immediately. And you don't spend > waiting time and slowing down other connections.
the same as above. The difference I don't understand is - why you used 'async-modes, if similar functionality can be achieve via /no-wait refinement ... hmm, maybe I am just missing something :-) -pekr-

 [19/32] from: m:koopmans2:chello:nl at: 23-May-2001 13:21


No-wait doesn't wait if there is no data. Async doesn't wait if there is data but less than you ask. Say there are 5 bytes of data on our port test, Then read-io test buffer 8 would block on a sync port, 'no-wait or not. Async would read the 5 bytes, throw an error that it would be blocking (that you catch) and you continue later on. --Maarten

 [20/32] from: petr:krenzelok:trz:cz at: 23-May-2001 13:33


Maarten Koopmans wrote:
> No-wait doesn't wait if there is no data. > Async doesn't wait if there is data but less than you ask.
<<quoted lines omitted: 3>>
> throw an error that it would be blocking (that you catch) and you continue > later on.
Ha! That's cool. Thanks for explanation ... -pekr-

 [21/32] from: brett:codeconscious at: 23-May-2001 21:31


Hi Maarten, I found a small bug in %rugby.r. It appears that you need to initialise fills in the functions called "fill-0". Otherwise works well. Thanks! Brett.

 [22/32] from: m:koopmans2:chello:nl at: 23-May-2001 14:27


Aren't locals initialized to none by default? Where did the bug occur? I haven't run into it yet myself. --Maarten

 [23/32] from: holger:rebol at: 23-May-2001 6:13


On Wed, May 23, 2001 at 08:00:09AM +0200, Petr Krenzelok wrote:
> - once max number of simultaneous connections is reached: > a) other copy of LOCAL Rebol could be 'launched, connected to master by TCP port
<<quoted lines omitted: 4>>
> instance, connected to "master" task, performing the same kind of functionality) > help to locally load balance connections handling?
Yes, somewhat, if the bottleneck is processing the requests itself. An alternative is to use load balancing in the FastCGI dispatcher.
> Other two question related to ports: > > - I noticed that Maarten used open/direct non buffered aproach? Does it have any > advantage upon using buffered ports, e.g. "blocking" issues?
open/direct is necessary in most situations because otherwise you would not get any data at all until the other end closes its connection.
> - I also noticed following piece of code. What does it do exactly, please - I > mean how does it influence port? > > set-modes conn [ async-modes: [read write]]
Don't use, don't touch, don't copy. Here there be dragons... 'async-modes is an RT-private port mode that we added temporarily for the implementation of /Express, to allow more flexibility in async socket operation. Any script using it WILL break and will have to be largely rewritten for Core 3.0. We will switch to handler-based model for async i/o then. That's why we intentionally did not document this. -- Holger Kruse [holger--rebol--com]

 [24/32] from: holger:rebol at: 23-May-2001 6:30


On Wed, May 23, 2001 at 01:21:00PM +0200, Maarten Koopmans wrote:
> No-wait doesn't wait if there is no data. > Async doesn't wait if there is data but less than you ask.
<<quoted lines omitted: 3>>
> throw an error that it would be blocking (that you catch) and you continue > later on.
No, not quite. In your scenario, without 'async-modes read-io would still only return the 5 bytes, but then the next read-io, on an empty port, would block. This is consistent with the way recv() in C works on blocking sockets. With 'async-modes read-io returns the 5 bytes normally, without error, but then the next call to read-io on an empty port throws an error instead of blocking. -- Holger Kruse [holger--rebol--com]

 [25/32] from: holger:rebol at: 23-May-2001 6:26


On Wed, May 23, 2001 at 12:38:04PM +0200, Petr Krenzelok wrote:
> the same as above. The difference I don't understand is - why you used > 'async-modes, if similar functionality can be achieve via /no-wait refinement > ...
/no-wait changes the behavior of 'copy. Without /no-wait 'copy waits until the other end closes the connection, with /no-wait 'copy waits until SOME data is available and returns it then. This mean /no-wait affects the way reading from a port interacts with end-of-file conditions. You need /no-wait together with /direct if you want to implement interactive protocols and use 'copy (instead of 'read-io). 'async-modes enables non-blocking operation of all port actions, including reading, writing, connecting and accepting connections on listen ports. It has nothing to do with end-of-file conditions. Again: don't use, don't use, don't use,... This was a quick internal hack for /Express and is NOT part of the official REBOL language. In Core 3.0 the 'async-modes word will go away, and we will provide an official API for async port operation that is much nicer and will, e.g., allow streaming, up/downloads in the background etc. -- Holger Kruse [holger--rebol--com]

 [26/32] from: cyphre:volny:cz at: 23-May-2001 15:47


Hello Holger,
> Any script using it WILL break and will have to be largely rewritten for > Core 3.0. We will switch to handler-based model for async i/o then. That's > why we intentionally did not document this. >
Ok, so when would be /Core 3.0 released? Will be also implemented async i/o in /View right after /Core? Cyphre

 [27/32] from: cyphre:volny:cz at: 23-May-2001 16:10


> 'async-modes enables non-blocking operation of all port actions, including > reading, writing, connecting and accepting connections on listen ports.
Just one question comes to my mind....Could be also event-port in /View asynchronous then? Regards, Cyphre

 [28/32] from: cyphre:volny:cz at: 23-May-2001 16:01


Hello its me again ;-)
> has nothing to do with end-of-file conditions. Again: don't use, don't
use,
> don't use,... This was a quick internal hack for /Express and is NOT part > of the official REBOL language. In Core 3.0 the 'async-modes word will go > away, and we will provide an official API for async port operation that is > much nicer and will, e.g., allow streaming, up/downloads in the background > etc. >
That sound really VERY interesting. Looks like I would be able to reach my visions in SWIS developing ;-) BTW when speaking about hacks will be also debugged/enhanced DRAW dialect? I'll post to feedback some bugs/sugestions regarding DRAW which I found while playing with it... Looking forward to "async future" ;-) Cyphre

 [29/32] from: holger:rebol at: 23-May-2001 7:38


On Wed, May 23, 2001 at 03:47:45PM +0200, Richard Smolak wrote:
> Ok, so when would be /Core 3.0 released?
We don't know yet. At the moment Core 3.0 is simply "the Core that comes after 2.x". No release date yet.
> Will be also implemented async i/o > in /View right after /Core?
Yes, of course. And in Command etc. -- Holger Kruse [holger--rebol--com]

 [30/32] from: holger:rebol at: 23-May-2001 7:41


On Wed, May 23, 2001 at 04:10:07PM +0200, Richard Smolak wrote:
> > 'async-modes enables non-blocking operation of all port actions, including > > reading, writing, connecting and accepting connections on listen ports. > > Just one question comes to my mind....Could be also event-port in /View > asynchronous then?
There is no need. The event port is already handler-based, even in View 1.2. In the earlier View betas you had to 'wait on event ports, but that is no longer the case since View 1.0. Basically the whole concept of event ports is transparent to the developer. -- Holger Kruse [holger--rebol--com]

 [31/32] from: brett:codeconscious at: 24-May-2001 1:14


Hi Maarten,
> Aren't locals initialized to none by default?
Yup. Therein lies the problem, because FOR needs something specified as end as in:
>> for i 1 none 1 []
** Script Error: for expected end argument of type: number series money time date char ** Where: halt-view ** Near: for i 1 none 1 Which is the error I received.
> Where did the bug occur? I haven't run into it yet myself. >
;fill a string with zeros (used for message lengths etc.) fill-0: func [ filly [string!] how-many [integer!] /local fills] [ fills: 0 ; <-- my addition ***** if how-many > length? filly [ fills: how-many - length? filly ] for filz 1 fills 1 [ ; <----- fills must not be none **** insert filly "0" ] return filly ] Regards, Brett

 [32/32] from: cyphre:volny:cz at: 23-May-2001 17:09


> There is no need. The event port is already handler-based, even in > View 1.2. In the earlier View betas you had to 'wait on event ports, > but that is no longer the case since View 1.0. Basically the whole > concept of event ports is transparent to the developer. >
Thanks for the useful information. I havent had a look at it since those old days...Have to investigate :-) Cyphre

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted