Hi,
I can't find any in depth online article on Drb, presenting anything
else than a simple server and client. I'd like to learn more on the
idea behind it, when it can be used and for what type of application
(for a client/server game?), how to manage clients (identifying them,
disconnecting them), comparison with TCP (if relevent), etc...
Could anyone point me a good article, or maybe just reply to my simple
subjects given above?
Many thanks,
Mickael.
Mickael Faivre-Macon wrote:
Hi,
I can't find any in depth online article on Drb, presenting anything
else than a simple server and client. I'd like to learn more on the
idea behind it, when it can be used and for what type of application
(for a client/server game?), how to manage clients (identifying them,
disconnecting them), comparison with TCP (if relevent), etc...Could anyone point me a good article, or maybe just reply to my simple
subjects given above?Many thanks,
Mickael.
I'm not sure anyone uses just drb ... it's more common to use drb via
the Rinda layer on top of drb. Try a search for Rinda ... there was a
talk about Rinda at RubyConf 2006.
I can't find any in depth online article on Drb, presenting anything
else than a simple server and client. I'd like to learn more on the
idea behind it,
The basic idea is to remove the hassle of communication between processes and make your code look and feel like it is running as a single process.
when it can be used and for what type of application
(for a client/server game?),
Any place you need transparent communication between processes.
how to manage clients (identifying them, disconnecting them),
You don't. DRb nodes are both clients and servers. You can restrict connections by both ACLs and SSL keys. You can restrict method calls in other ways.
comparison with TCP (if relevent), etc...
Huh? TCP is a much lower level protocol than DRb. (Also, DRb is multi-protocol)
On Oct 30, 2006, at 2:35 AM, Mickael Faivre-Macon wrote:
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
M. Edward (Ed) Borasky wrote:
Mickael Faivre-Macon wrote:
Hi,
I can't find any in depth online article on Drb, presenting anything
else than a simple server and client. I'd like to learn more on the
idea behind it, when it can be used and for what type of application
(for a client/server game?), how to manage clients (identifying them,
disconnecting them), comparison with TCP (if relevent), etc...Could anyone point me a good article, or maybe just reply to my simple
subjects given above?Many thanks,
Mickael.I'm not sure anyone uses just drb ... it's more common to use drb via
the Rinda layer on top of drb. Try a search for Rinda ... there was a
talk about Rinda at RubyConf 2006.
For a fairly simple example of how drb can be used to enable client-server/multiuser functionality, take a look at KirbyBase (http://netpromi.com/ruby_kirbybase.html\). Drb works great and made implementing a client/server version of the dbms very easy. I had to throw in some mutex code to make sure separate user threads didn't step on each other, but it was fairly straightforward.
Jamey
Confidentiality Notice: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. If you are not the intended recipient(s), you are hereby notified that any dissemination, unauthorized review, use, disclosure or distribution of this email and any materials contained in any attachments is prohibited. If you receive this message in error, or are not the intended recipient(s), please immediately notify the sender by email and destroy all copies of the original message, including attachments.
Funny, I use DRb by itself a lot, but have never yet used Rinda for a
production application. DRb by itself works just fine for all of my
needs, but then I'm not trying (yet) to build an application that will
do automated service discovery. I don't see why you say it's more
common to use Rinda on top of DRb. While I admit that Rinda is
interesting, it still leaves you with the problem of the actual DRb
services that you'll publish on top of it.
Anyway, to answer the GP poster's question, I learned all I needed to
know about programming DRb from the following sites:
http://segment7.net/projects/ruby/drb/index.html
http://wiki.rubygarden.org/Ruby/page/show/DrbTutorial
Eric Hodel's segment7 site has a lot of stuff; even includes a
tutorial on how to properly run DRb over SSL, and it appears to be one
of the few English language sites describing how to use Rinda.
By the way, DRb is really not that hard. From experience, DRb actually
makes writing distributed objects TOO easy, so easy that you wind up
making mistakes like forgetting that some object is actually a remote
one, and consequently also forgetting the necessary error checking
that that would entail, resulting in problems when you try using such
remote services over something less reliable than a private LAN.
On 10/30/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
I'm not sure anyone uses just drb ... it's more common to use drb via
the Rinda layer on top of drb. Try a search for Rinda ... there was a
talk about Rinda at RubyConf 2006.
Jamey Cribbs wrote:
M. Edward (Ed) Borasky wrote:
Mickael Faivre-Macon wrote:
Hi,
I can't find any in depth online article on Drb, presenting anything
else than a simple server and client. I'd like to learn more on the
idea behind it, when it can be used and for what type of application
(for a client/server game?), how to manage clients (identifying them,
disconnecting them), comparison with TCP (if relevent), etc...Could anyone point me a good article, or maybe just reply to my simple
subjects given above?Many thanks,
Mickael.I'm not sure anyone uses just drb ... it's more common to use drb via
the Rinda layer on top of drb. Try a search for Rinda ... there was a
talk about Rinda at RubyConf 2006.
For a fairly simple example of how drb can be used to enable client-server/multiuser functionality, take a look at KirbyBase (http://netpromi.com/ruby_kirbybase.html\). Drb works great and made implementing a client/server version of the dbms very easy. I had to throw in some mutex code to make sure separate user threads didn't step on each other, but it was fairly straightforward.
Oops, that should have been http://netpromi.com/kirbybase_ruby.html\!
Jamey
Confidentiality Notice: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. If you are not the intended recipient(s), you are hereby notified that any dissemination, unauthorized review, use, disclosure or distribution of this email and any materials contained in any attachments is prohibited. If you receive this message in error, or are not the intended recipient(s), please immediately notify the sender by email and destroy all copies of the original message, including attachments.
I believe the other poster was referring more to Rinda::Tuplespace than Rinda::RingServer.
James Edward Gray II
On Oct 30, 2006, at 7:42 PM, Dido Sevilla wrote:
While I admit that Rinda is
interesting, it still leaves you with the problem of the actual DRb
services that you'll publish on top of it.
Hi Dido,
This site is indeed the best site on Drb but do not answer all my questions 
But thanks for the link !
Mickael.
On 10/31/06, Dido Sevilla <dido.sevilla@gmail.com> wrote:
On 10/30/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
> I'm not sure anyone uses just drb ... it's more common to use drb via
> the Rinda layer on top of drb. Try a search for Rinda ... there was a
> talk about Rinda at RubyConf 2006.Funny, I use DRb by itself a lot, but have never yet used Rinda for a
production application. DRb by itself works just fine for all of my
needs, but then I'm not trying (yet) to build an application that will
do automated service discovery. I don't see why you say it's more
common to use Rinda on top of DRb. While I admit that Rinda is
interesting, it still leaves you with the problem of the actual DRb
services that you'll publish on top of it.Anyway, to answer the GP poster's question, I learned all I needed to
know about programming DRb from the following sites:http://segment7.net/projects/ruby/drb/index.html
http://wiki.rubygarden.org/Ruby/page/show/DrbTutorialEric Hodel's segment7 site has a lot of stuff; even includes a
tutorial on how to properly run DRb over SSL, and it appears to be one
of the few English language sites describing how to use Rinda.By the way, DRb is really not that hard. From experience, DRb actually
makes writing distributed objects TOO easy, so easy that you wind up
making mistakes like forgetting that some object is actually a remote
one, and consequently also forgetting the necessary error checking
that that would entail, resulting in problems when you try using such
remote services over something less reliable than a private LAN.
--
Mickael.
Coding an AI ! http://faivrem.googlepages.com/antbattle
Rinda::RingServer and friends are for automated service discovery and sit on top of Rinda::TupleSpace. Whenever you need communication beyond what a set of Queues can provide a TupleSpace becomes your friend. The best book on how to use Linda/Rinda is:
How To Write Parallel Programs: A First Course by Nicholas Carriero, David Gelernter 1990
If you just want autodiscovery, RindyDingy wraps up all that hassle in an easy package.
On Oct 30, 2006, at 5:42 PM, Dido Sevilla wrote:
On 10/30/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:
I'm not sure anyone uses just drb ... it's more common to use drb via
the Rinda layer on top of drb. Try a search for Rinda ... there was a
talk about Rinda at RubyConf 2006.Funny, I use DRb by itself a lot, but have never yet used Rinda for a
production application. DRb by itself works just fine for all of my
needs, but then I'm not trying (yet) to build an application that will
do automated service discovery. I don't see why you say it's more
common to use Rinda on top of DRb. While I admit that Rinda is
interesting, it still leaves you with the problem of the actual DRb
services that you'll publish on top of it.
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
Hi Jamey,
Thanks for the code.
Actually, I don't see in this code where you identify ("discriminate",
not "authenticate") the clients. I'd like to see if it is possible for
DRB to know who is the client. How can you manage connections, etc...
Mickael.
On 10/30/06, Jamey Cribbs <jcribbs@netpromi.com> wrote:
Jamey Cribbs wrote:
> M. Edward (Ed) Borasky wrote:
>> Mickael Faivre-Macon wrote:
>>
>>> Hi,
>>>
>>> I can't find any in depth online article on Drb, presenting anything
>>> else than a simple server and client. I'd like to learn more on the
>>> idea behind it, when it can be used and for what type of application
>>> (for a client/server game?), how to manage clients (identifying them,
>>> disconnecting them), comparison with TCP (if relevent), etc...
>>>
>>> Could anyone point me a good article, or maybe just reply to my simple
>>> subjects given above?
>>>
>>> Many thanks,
>>> Mickael.
>>>
>> I'm not sure anyone uses just drb ... it's more common to use drb via
>> the Rinda layer on top of drb. Try a search for Rinda ... there was a
>> talk about Rinda at RubyConf 2006.
>>
> For a fairly simple example of how drb can be used to enable
> client-server/multiuser functionality, take a look at KirbyBase
> (http://netpromi.com/ruby_kirbybase.html\). Drb works great and made
> implementing a client/server version of the dbms very easy. I had to
> throw in some mutex code to make sure separate user threads didn't
> step on each other, but it was fairly straightforward.Oops, that should have been http://netpromi.com/kirbybase_ruby.html\!
Jamey
Confidentiality Notice: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. If you are not the intended recipient(s), you are hereby notified that any dissemination, unauthorized review, use, disclosure or distribution of this email and any materials contained in any attachments is prohibited. If you receive this message in error, or are not the intended recipient(s), please immediately notify the sender by email and destroy all copies of the original message, including attachments.