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

Ann Rugby 4.3

 [1/25] from: m:koopmans2:chello:nl at: 23-Nov-2001 14:10


You have this when using Rugby with rebol/view. Especially the deferred http and and deferred and oneway TCP modes give you the possibility to do this kind of things. The problem with P2P is the network topology (graph), which you solve by peer discovery and routing algorithms. Which is something different than transport = Rugby. Whi is client and server in Rugby depensd on how you program: a script can easily change roles. Look at the demo script I posted yesterday (Rugby P2P chat sample) HTH, Maarten *** Gabriele wrote: That is right, but I can still see an architectural disadvantage of Rugby: it being client/server only. I believe fully symmetrical peer-to-peer connections can be a great advantage in some cases; I think I will try to integrate Rugby in a symmetrical system some day... Regards, Gabriele.

 [2/25] from: g:santilli:tiscalinet:it at: 23-Nov-2001 19:01


Hello Petr! On 22-Nov-01, you wrote: PK> Not necessarily. Rugby is tine - you can run both client and PK> server in one app. It just doesn't seem to support permanent Yes, but that means having two asymmetrical connections... Anyway, Rugby is fine as it is, it's just that I think it cannot solve ANY problem in an efficient way... Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [3/25] from: petr:krenzelok:trz:cz at: 23-Nov-2001 22:32


Gabriele Santilli wrote:
>Hello Petr! > >On 22-Nov-01, you wrote: > > PK> Not necessarily. Rugby is tine - you can run both client and > PK> server in one app. It just doesn't seem to support permanent > >Yes, but that means having two asymmetrical connections... >
So, Maarten, is that a problem to add some kind of /keep-alive connection, along to already existing /one-way, /deferred? :-)
> >Anyway, Rugby is fine as it is, it's just that I think it cannot >solve ANY problem in an efficient way... >
Of course! Rugby is currently really good to remote service execution. So - request brokering. Simple, powerfull, secured. -pekr-

 [4/25] from: koopmans:itr:ing:nl at: 21-Nov-2001 14:56


Hi all, I just released Rugby 4.3 , the best version ever. All upgrade! Download it at http://www.rebolforces.com/~erebol/ Rugby is a rebol request broker that allows you to build distributed computing applications in a few lines of code! A great example is Graham's GoRim. What's new: - Transparent error propagation. An error on the server is now serialized and instantiated on the client as the same error! This makes it easy to do distributed debugging. - Http server side handler is improved in the way it clears the buffers at the end of a request. This may (or may not) fix the runaway problem after a long period of time where servers start eating CPU time on some platforms. - Functions now support refinements! YES! - Totally renewed stub generation engine for refinement support. As a side effect you can now import multiple services in the global namespace. - Some minor performance improvements compared to 4.3e resulting in a 7-10% increase overall. I will add extra documentation in the next few weeks, although the current documentation should be good enough for most of you. Please don't hesitate to ask me questions by email as specfied on the web site. Download it at http://www.rebolforces.com/~erebol/ The mirror on http://www.vrijheid.net will be updated within a week. Enjoy, Maarten

 [5/25] from: petr:krenzelok:trz:cz at: 21-Nov-2001 15:54


wooohooo, well, let's dig into it ... Maarten Koopmans wrote:
> Hi all, > > I just released Rugby 4.3 , the best version ever. All upgrade! > > Download it at http://www.rebolforces.com/~erebol/ > > Rugby is a rebol request broker that allows you to build distributed > computing applications in a few lines of code! A great example is Graham's > GoRim.
Yes, it is. However, let's prove we are right. I don't call GoRim a success yet, nor do I call RIM a success. I think that polling aproach for instant chat is the wrong way to go. I don't say Rugby is bad architecture, as it is not and it has its future with Rebol! However - does its transport mechanism allow us to build something more real-time, in quality level of IRC? Does IRC use polling? Why should XYZ users contact/poll server each N secs, if there is no message available? Now - would it be possible to build another scenario using Rugby? Frank showed us with his IRC client, that communication using Rebol CAN be really instant. We currently can - - call remote function (via imported stubs,or directly remotely) - call remote function /deffered - is connection closed here? - call remote function /oneway - is connection closed here? - call remote function /wait-for-result - does this block whole user interface, till we don't receive answer? What about following: - chat client running rugby client and server. - chat client connects to server - server registers client's listening ports, and connects to it, keeps the connection * - once message arrives to server, it distributes it to all client channels ... *But probably, we've got problem with firewalls here ... It's not critique, just reality - I showed GoRim to several friends, and typica answer was - why is it so slow in response? What is your opinion on the subject?
> > What's new: > > - Transparent error propagation. An error on the server is now serialized and > instantiated on the client as the same error! This makes it easy to do > distributed debugging. >
Be carefull with error ;-) I pasted Graham one error message, which showed whole path in my system on my server. I call it a security risk :-)
> - Http server side handler is improved in the way it clears the buffers at > the end of a request. This may (or may not) fix the runaway problem after a > long period of time where servers start eating CPU time on some platforms. >
great!
> - Functions now support refinements! YES! > - Totally renewed stub generation engine for refinement support. As a side
<<quoted lines omitted: 4>>
> documentation should be good enough for most of you. Please don't hesitate to > ask me questions by email as specfied on the web site.
Everything great! -pekr-

 [6/25] from: holger:rebol at: 21-Nov-2001 8:07


On Wed, Nov 21, 2001 at 03:54:34PM +0100, Petr Krenzelok wrote:
> *But probably, we've got problem with firewalls here ...
Yes. That's why for most business applications tunnelling through HTTP and using polling is a necessity. -- Holger Kruse [holger--rebol--com]

 [7/25] from: petr:krenzelok:trz:cz at: 21-Nov-2001 17:13


[holger--rebol--com] wrote:
> On Wed, Nov 21, 2001 at 03:54:34PM +0100, Petr Krenzelok wrote: > > > *But probably, we've got problem with firewalls here ... > > Yes. That's why for most business applications tunnelling through HTTP > and using polling is a necessity.
Heh, you're alive holger? :-) Well, is that the same reason why IRC's DCC doesn't work? Probably yes. Well, Rugby is not slow. So why does chat client based upon it need to use polling? IRC doesn't do so probably, and I am IRCing from behind the firewall here. Hmm, although not probably using http tunneling ... On the other hand polling means limiting - I can't simply imagine hundreds of users polling server each sec or three - what a massive communication .... Thanks, -pekr-

 [8/25] from: mario:cassani:icl at: 21-Nov-2001 16:28


Hi Holger,
> > *But probably, we've got problem with firewalls here ... > > Yes. That's why for most business applications tunnelling through HTTP > and using polling is a necessity.
I am actually behind an NTLM MS Proxy and I cannot use REBOL but locally. Do you plan to add NT LAN Manager protocol authentication and handling to REBOL? Windows is unfortunately the widest spread OS and big companies are "locked" behind this kind of a firewall. Do you agree that REBOL reputation is influenced by this? Best regards Mario Cassani

 [9/25] from: mario:cassani:icl at: 21-Nov-2001 16:37


Hi Petr,
> On the other hand polling means limiting - I can't simply > imagine hundreds > of users polling server each sec or three - what a massive > communication > ....
welcome to M$ .NET! In a recent network performance test Windows programs we produce were eating network resources form tens to hundreds times other systems (DOS, Unix,...) did. (I cannot disclose the details due to my company policies). The worst part is: guess which is the widest spread OS ever... Mario

 [10/25] from: holger:rebol at: 21-Nov-2001 8:50


On Wed, Nov 21, 2001 at 05:13:35PM +0100, Petr Krenzelok wrote:
> Heh, you're alive holger? :-) Well, is that the same reason why IRC's DCC > doesn't work? Probably yes. Well, Rugby is not slow. So why does chat > client based upon it need to use polling? IRC doesn't do so probably, and > I am IRCing from behind the firewall here. Hmm, although not probably > using http tunneling ...
IRC does not work through firewalls that block outgoing communication (other than HTTP), like most corporate firewalls do. -- Holger Kruse [holger--rebol--com]

 [11/25] from: holger:rebol at: 21-Nov-2001 8:51


On Wed, Nov 21, 2001 at 04:28:44PM -0000, Cassani Mario wrote:
> Hi Holger, > > > *But probably, we've got problem with firewalls here ...
<<quoted lines omitted: 4>>
> but locally. Do you plan to add NT LAN Manager protocol > authentication and handling to REBOL?
Yes. -- Holger Kruse [holger--rebol--com]

 [12/25] from: ptretter:charter at: 21-Nov-2001 11:00


IRC does do polling in the form of Ping and Pongs. If it detects that a client is idle it will send a Ping response in which the client must respond with a Pong or risk being disconnected. It works very well actually. As for getting thru a firewall with IRC than most likely your firewall is allowing IRC ports to pass thru. Paul Tretter

 [13/25] from: robert:muench:robertmuench at: 21-Nov-2001 18:10


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 6>>
>> authentication and handling to REBOL? > Yes.
This is good news! AFAIK even Opera isn't able to handle this yet... that's why I have to use IE most of the time. Robert

 [14/25] from: max:quazart at: 21-Nov-2001 11:44


Hi Mario , hasn't someone already implemented a NTLM proxy handler (or is working on it) ? I seem to remember this discussion before and hadn't someone posted once that he'd successfully cracked the protocol and was working on it !? -MAx

 [15/25] from: petr:krenzelok:trz:cz at: 21-Nov-2001 19:21


Paul Tretter wrote:
>IRC does do polling in the form of Ping and Pongs. If it detects that a >client is idle it will send a Ping response in which the client must respond >with a Pong or risk being disconnected. >
Yes, but then server polls client, not in reverse. It does so probably in some periods. However - there is no need for client-to-server communication, if we don't actually send message, while Gorim, Express (IOS) polling means constant flooding of server in set period of time, e.g. each 3 sec. That sounds terrible, but there is not probably any way around ...
> It works very well actually. As >for getting thru a firewall with IRC than most likely your firewall is >allowing IRC ports to pass thru. >
Yes, it is so. But well, if company really works to allow ICQ or IRC or some other service, because it finds it usefull, why not to do so? There should be both ways possible, while I think that Rugby does not allow something like that by its architecture ... I can be wrong, as I haven't studied Rugby completly. Deferred ports, however, seem to store pairs of index, port-objects, to check back later for the result, but on the server side web-handler calls stop o/port, and client port is killed. btw: does anyone here know, how does Jabber work in the principle? Is it request broker like Rugby is, or? .... -pekr-

 [16/25] from: andreas:bolka:gmx at: 21-Nov-2001 19:22


Wednesday, November 21, 2001, 7:21:56 PM, Petr wrote:
> btw: does anyone here know, how does Jabber work in the principle? > Is it request broker like Rugby is, or? ....
jabber opens a port to a server over which all traffic flows. just like IRC or ICQ. jabber has problems with working behind HTTP proxies as well. -- Best regards, Andreas mailto:[andreas--bolka--gmx--net]

 [17/25] from: doublec:acc at: 22-Nov-2001 8:30


HttpHost will enable you to use Rebol behind an NTLM proxy: http://www.htthost.com Chris.
>>> [Mario--Cassani--icl--com] 11/22/01 05:28 >>>
I am actually behind an NTLM MS Proxy and I cannot use REBOL but locally. Do you plan to add NT LAN Manager protocol authentication and handling to REBOL?

 [18/25] from: m:koopmans2:chello:nl at: 21-Nov-2001 23:03


Hi Petr, The polling mechanism is due to firewalls. In Rugby you can have Rebol processes that are client AND server in Rebol/View, so your scenario is easily implemented then. IF your company's firewall allows both ingoing AND outgoing http traffic (or TCP for that matter) of course. It is *not* a Rugby architecture problem, but merely network management. Graham's approach is good, but as we are all on different continents and have different ISP's.... Compare what Graham has done to the speed of chatting in ICQ or Yahho behind a firewall (*if* that works). So what I am saying is that provided your network is properly configured and you use Rebol/View you can do what you describe (easy!!!). Too late now but I'll send a simple view script demonstrating it to this ml tomorrow. And I'll fix the find? thing (as mailed before, wrong version ftp'ed, CVS woes...) --Maarten

 [19/25] from: gchiu:compkarori at: 22-Nov-2001 13:28


Maarten, Is the new version of Rugby compatible with previous versions? I am just wondering what happens when client and server run different versions. -- Graham Chiu

 [20/25] from: petr:krenzelok:trz:cz at: 22-Nov-2001 1:27


Graham Chiu wrote:
>Maarten, > >Is the new version of Rugby compatible with previous >versions? I am just wondering what happens when client and >server run different versions. >
I don't really know - although I repaired found bug, I was not able to connect anymore, or I got errors later when running gorim ... I will wait for Maarten to post official version ... -pekr-

 [21/25] from: petr:krenzelok:trz:cz at: 22-Nov-2001 1:34


Graham Chiu wrote:
>Maarten, > >Is the new version of Rugby compatible with previous >versions? I am just wondering what happens when client and >server run different versions. > >-- >Graham Chiu >
re new bugs - namely: ->> do http://www.rebol.cz/~asko/gorim-rebolcz.r ** Script Error: http-result-available? expected index argument of type: integer ** Where: process-event-queue ** Near: not http-result-available? ticket ->> I just replaced rugby on client and server side with latest version .... no change to gorim, no change to game-server ... I wonder what is going on ... -pekr-

 [22/25] from: gchiu:compkarori at: 22-Nov-2001 14:26


> ->> do http://www.rebol.cz/~asko/gorim-rebolcz.r > ** Script Error: http-result-available? expected index
<<quoted lines omitted: 8>>
> what is going > on ...
Hehe. That's why I don't run the beta software on my site :) -- Graham Chiu

 [23/25] from: koopmans:itr:ing:nl at: 22-Nov-2001 9:44


Hi All, I have ftp'ed the correct version to the site, sorry for any inconvenience... http://www.rebolforces.com/~erebol --Maarten

 [24/25] from: g:santilli:tiscalinet:it at: 22-Nov-2001 14:36


Maarten Koopmans wrote:
> It is *not* a Rugby architecture problem, but merely network management.
That is right, but I can still see an architectural disadvantage of Rugby: it being client/server only. I believe fully symmetrical peer-to-peer connections can be a great advantage in some cases; I think I will try to integrate Rugby in a symmetrical system some day... Regards, Gabriele. -- Gabriele Santilli <[giesse--writeme--com]> - Amigan - REBOL programmer Amiga Group Italia sez. L'Aquila -- http://www.amyresource.it/AGI/

 [25/25] from: petr:krenzelok:trz:cz at: 22-Nov-2001 14:52


Gabriele Santilli wrote:
> Maarten Koopmans wrote: > > It is *not* a Rugby architecture problem, but merely network management.
<<quoted lines omitted: 3>>
> think I will try to integrate Rugby in a symmetrical system some > day...
Not necessarily. Rugby is tine - you can run both client and server in one app. It just doesn't seem to support permanent connections. It does so using /deferred, but then you have to check back for the result = polling .... -pekr-

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