[REBOL] Re: Async Rugby
From: henrik:webz:dk at: 3-May-2007 11:49
On 02/05/2007, at 11:46, Gabriele Santilli wrote:
> 2007/5/1, Henrik Mikael Kristensen <henrik-webz.dk>:
>
>> I'm inclined to do a rewrite of hipe.r as Maarten mentions on AltME:
>
> You might also just use /Services and the RPC service. It depends on
> your app, as /Services may not be mature enough for some kind of apps.
> However, I think both Gregg and Robert are using it without problems.
> (Robert also has an experimental version with some http proxy support
> - if it's working for him we can release that somewhere.)
I evaluated /Services early in 2006 to see whether it would be useful
for my work and while it's good to code for, some nasty hangs during
testing prevented me from moving further with it. I learned back then
that this is possibly a design flaw in /Services, due to the lack of
async and it would not be possible to fix before R3. This was since
refuted as being fully possible to fix for R2, but is a priority
issue (no time to fix). The docs say it's a design flaw, so I don't
know what to believe. :-) But in short, it's not finished yet and I
have no control over it.
I do plan to move over to /Services for R3 when it gets completed.
I have spent many hours writing apps around Rugby, since the
beginning of 2006 and am fully depending on it now in my own
development pipeline. I'm in the process of implementing solutions
for customers using Rugby. I know what's going on in about 25% of the
Rugby code. As I've been digging deeper into it, I've found numerous
hangs, bugs and performance issues. Most are fixed and some are hard
to fix in Rugby's current form, due to port bugs in REBOL.
Here's an overview of what problems there currently are with Rugby,
in order of priority:
1. It hangs REBOL showing 0% CPU usage when a server tries to deliver
data back to the client and the client is gone. This is due to a port
bug, where REBOL seems to wait indefinitely for data. If it happens,
both client and server must be restarted. The risk of hang grows if
the client is on a slow, unreliable connection. This is a showstopper
that must be fixed.
2. It's not async. Sending 1 MB data to a 56k modem from server to
client will hold up all other operations. This is fixable, but
difficult. It would boost Rugby performance with multiple clients a
lot. Even with number 1 fixed, Rugby is still very usable without async.
3. Not all functions and content for transmission can be sent exactly
as originally written. This is a thing that you can work around.
4. Some crashes when using /secure, but these are so random and rare,
that they are hard to trace. When not using /secure, these crashes
don't occur at all.
5. A certain port bug (which outputs NONE! when you read from the
port) means that the server reading data from the client is a bit
slower than it needs to be. It has to be throttled to read less than
3 kb at a time. However the fixes I made have boosted performance
tremendously over the original Rugby Version 5.0.0, which only read
16 bytes at a time and it's reliable so far.
6. The security in Rugby is not that great and can be circumvented
using code injection, but no solution has yet been found. I'm not
working on this, since I use Rugby primarily in a closed LAN.
The hang in number 1 requires expert assistance to fix. But if at
least this hang is fixed, Rugby will be very reliable when not using /
secure, and it will become possible to recover from a network failure
without having to restart all servers and clients.
As you can see, Rugby is a better known field to me than /Services
and I think I know exactly what needs to be fixed for it to be 99,97%
reliable for use with multiple clients in an unreliable network.
It's now a matter of how to fix it, which is where I'm stumped. :-)
--
Regards,
Henrik Mikael Kristensen