Can anyone tell me the difference between Distributed ruby and rinda?
···
--
Posted via http://www.ruby-forum.com/.
Rinda uses Distributed Ruby (DRb) in its Tuplespace implementation.
That being said, you can use DRb without using Rinda. I view DRb as
similar to many other languages' remoting frameworks; Corba, JINI,
Httpinvoker, etc. The main advantage is that DRb has a lower barrier
to entry.
I have no experience with other tuplespace implementations but I've
heard it was originally based off a java project called Linda.
Playing around with Rinda actually helped me in understanding Erlang's
process 'mail boxes', which I find quite similar.
···
On Aug 29, 7:48 am, Hema Latha <hema_asp...@yahoo.co.in> wrote:
Can anyone tell me the difference between Distributed ruby and rinda?
--
Posted viahttp://www.ruby-forum.com/.
Linda and Lindaspaces long predate Java. There's actually a rigorous and
sophisticated mathematical foundation for them, and a long history of
pre-Java implementations, including some of my own from perhaps a dozen
years ago.
If you're interested in Erlang-like "spawned processes" for Ruby, they were
just added to EventMachine. Sync to the head revision and look at the test
cases. As soon as they get a few more features and documentation, they'll be
released. There's also some recent discussion of them on the EventMachine
mailing list.
···
On 8/30/07, brenton.leanhardt@gmail.com <brenton.leanhardt@gmail.com> wrote:
I have no experience with other tuplespace implementations but I've
heard it was originally based off a java project called Linda.
Playing around with Rinda actually helped me in understanding Erlang's
process 'mail boxes', which I find quite similar.
Francis Cianfrocca wrote:
If you're interested in Erlang-like "spawned processes" for Ruby, they were
just added to EventMachine. Sync to the head revision and look at the test
cases. As soon as they get a few more features and documentation, they'll be
released. There's also some recent discussion of them on the EventMachine
mailing list.
Thank you from the bottom of my heart for this!! Just out of curiosity,
are you going to present this at a Ruby conference in the near future??
The most interesting feature (being able to send messages to "spawned
processes" that are resident in other O/S processes or on other machines)
isn't done yet. I'm not that thrilled with how Erlang does it, by the way
(IP addresses and ranges of well-known ports) but I haven't thought of
anything better. DNS service records, maybe?
Presenting this somewhere would be fun... 
···
On 8/30/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
Francis Cianfrocca wrote:
> If you're interested in Erlang-like "spawned processes" for Ruby, they
were
> just added to EventMachine. Sync to the head revision and look at the
test
> cases. As soon as they get a few more features and documentation,
they'll be
> released. There's also some recent discussion of them on the
EventMachine
> mailing list.Thank you from the bottom of my heart for this!! Just out of curiosity,
are you going to present this at a Ruby conference in the near future??
Francis Cianfrocca wrote:
Francis Cianfrocca wrote:
If you're interested in Erlang-like "spawned processes" for Ruby, they
were
just added to EventMachine. Sync to the head revision and look at the
test
cases. As soon as they get a few more features and documentation,
they'll be
released. There's also some recent discussion of them on the
EventMachine
mailing list.
Thank you from the bottom of my heart for this!! Just out of curiosity,
are you going to present this at a Ruby conference in the near future??The most interesting feature (being able to send messages to "spawned
processes" that are resident in other O/S processes or on other machines)
isn't done yet. I'm not that thrilled with how Erlang does it, by the way
(IP addresses and ranges of well-known ports) but I haven't thought of
anything better.
Well ... you need something that's OS-agnostic and network agnostic,
which pretty much ties you to something "universal" like TCP/IP,
sockets, ports, etc. I don't know much about Windows or MacOS, but I'm
reasonably sure this stuff is about as efficient as it can be on Linux
and Solaris, and it's *so* tunable. 
Are there any "parallel
network-connected clustering" techniques that *don't* depend on TCP/IP?
Presenting this somewhere would be fun...
I'm sure MountainWest RubyConf next spring would love to have you.
···
On 8/30/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
You might like to take a look at DNS NAPTR records. They're not exactly well supported yet outside of ENUM projects, but they have lots of flexibility that you might find useful.
At some point in the non-too-distant future I even hope to publish a decent Ruby library for handling them as part of my RINDR DNS server project.
Ellie
Eleanor McHugh
Games With Brains
···
On 30 Aug 2007, at 15:14, Francis Cianfrocca wrote:
The most interesting feature (being able to send messages to "spawned
processes" that are resident in other O/S processes or on other machines)
isn't done yet. I'm not that thrilled with how Erlang does it, by the way
(IP addresses and ranges of well-known ports) but I haven't thought of
anything better. DNS service records, maybe?
----
raise ArgumentError unless @reality.responds_to? :reason
Oh it'll be TCP, all right. I was just thinking of the way that Erlang uses
to specify PIDs, with strings containing embedded machine identifiers. But
we know that the Erlang way works, because Ericsson supposedly has
distributed applications with literally millions of distributed processes.
···
On 8/30/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
>
> The most interesting feature (being able to send messages to "spawned
> processes" that are resident in other O/S processes or on other
machines)
> isn't done yet. I'm not that thrilled with how Erlang does it, by the
way
> (IP addresses and ranges of well-known ports) but I haven't thought of
> anything better.Well ... you need something that's OS-agnostic and network agnostic,
which pretty much ties you to something "universal" like TCP/IP,
sockets, ports, etc. I don't know much about Windows or MacOS, but I'm
reasonably sure this stuff is about as efficient as it can be on Linux
and Solaris, and it's *so* tunable.
network-connected clustering" techniques that *don't* depend on TCP/IP?
Francis Cianfrocca wrote:
Oh it'll be TCP, all right. I was just thinking of the way that Erlang uses
to specify PIDs, with strings containing embedded machine identifiers. But
we know that the Erlang way works, because Ericsson supposedly has
distributed applications with literally millions of distributed processes.
And just look at some of the options the Linux kernel (2.6.22) provides
just for congestion control and quality of service:
--- TCP: advanced congestion control
<M> Binary Increase Congestion (BIC) control
<*> CUBIC TCP
<M> TCP Westwood+
<M> H-TCP
<M> High Speed TCP
<M> TCP-Hybla congestion control algorithm
<M> TCP Vegas
<M> Scalable TCP
<M> TCP Low Priority
<M> TCP Veno
Default TCP congestion control (Cubic) --->
[*] QoS and/or fair queueing
Packet scheduler clock source (CPU cycle counter) --->
--- Queueing/Scheduling
<M> Class Based Queueing (CBQ)
<M> Hierarchical Token Bucket (HTB)
<M> Hierarchical Fair Service Curve (HFSC)
<M> ATM Virtual Circuits (ATM)
<M> Multi Band Priority Queueing (PRIO)
<M> Random Early Detection (RED)
<M> Stochastic Fairness Queueing (SFQ)
<M> True Link Equalizer (TEQL)
<M> Token Bucket Filter (TBF)
<M> Generic Random Early Detection (GRED)
<M> Differentiated Services marker (DSMARK)
<M> Network emulator (NETEM)
<M> Ingress Qdisc
--- Classification
<M> Elementary classification (BASIC)
<M> Traffic-Control Index (TCINDEX)
<M> Routing decision (ROUTE)
<M> Netfilter mark (FW)
<M> Universal 32bit comparisons w/ hashing (U32)
[*] Performance counters support
[*] Netfilter marks support
<M> IPv4 Resource Reservation Protocol (RSVP)
<M> IPv6 Resource Reservation Protocol (RSVP6)
[*] Extended Matches
(32) Stack size
<M> Simple packet data comparison
<M> Multi byte comparison
<M> U32 key
<M> Metadata
<M> Textsearch
[*] Actions
<M> Traffic Policing
<M> Generic actions
[*] Probability support
<M> Redirecting and Mirroring
<M> IPtables targets
<M> Packet Editing
< > Simple Example (Debug)
[*] Incoming device classification
--- Rate estimator
Someone insanely geekier than I am ought to be able to squeeze all the
delays out of this given all those options.