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