Hi, I''m looking at writing an eventmachine-based DRb server, but I wanted to check whether anyone knew of any existing work in this area? Google found one reference in the eventmachine-talk archives: On Wed Jun 14 13:18:19 EDT 2006, Jeff Rose <rosejn at gmail.com> wrote: Subject: machining away [...]> > server = MasterServer.new > > # This block will be executed for each new connection created. > TCPServer.new(host, port) do |dispatcher| > LineHandler.new(dispatcher) > HTTPHandler.new(dispatcher, my_config) > SOAPHandler.new(dispatcher, my_config) > server.new_connection(dispatcher) > ... # Anything else you need to do per connection > end > > > On top of this infrastructure we can create a variety of server classes > that encapsulate a full stack and make it really easy to implement > higher level services. It should be as easy to use something like an > event based DRB implementation, for example, as it is to use the current > synchronous one.This looks like just the sort of thing I want to do. (My DRb server would be only one of several protocols I''d be handling.) Note, I''m developing on Wind''ohs, and am currently using EventMachine version 0.5.3. Should I be using a later version from SVN? I seem to have formed the impression (possibly mistaken) that development versions of EM might not yet be Windows-compatible, so I''ve stayed with 0.5.3 so far. I am just getting acquainted with EM, and this DRb server would be my first project using it. So any tips such as "go ahead and develop with 0.5.3" or, "use a later SVN version to take advantage of functionality XYZ" would be appreciated. Thanks! Bill
Bill, use the latest snap. The only stuff that is still a little frowsy is the pure-Ruby implementation. Everything else is solid. I can send you a 0.7.0 binary gem that is known to work on Windows if you like. There is one current missing feature in Windows: the #defer functionality does not instantly interrupt the main loop on completion but does so with about 0.25 second latency. If that is critical for you, I''ll get it fixed asap. I''d like to hear more about how you''re attacking the DRb problem. One thing I''ve been thinking about adding is a user-defined message capability. This would function exactly like message queueing. With a persistence engine behind it, it would behave like assured-delivery MQ. Might that be helpful for you? On 8/22/06, Bill Kelly <billk at cts.com> wrote:> Hi, > > I''m looking at writing an eventmachine-based DRb server, but > I wanted to check whether anyone knew of any existing work in > this area? > > Google found one reference in the eventmachine-talk archives: > > On Wed Jun 14 13:18:19 EDT 2006, Jeff Rose <rosejn at gmail.com> wrote: > Subject: machining away > [...] > > > > server = MasterServer.new > > > > # This block will be executed for each new connection created. > > TCPServer.new(host, port) do |dispatcher| > > LineHandler.new(dispatcher) > > HTTPHandler.new(dispatcher, my_config) > > SOAPHandler.new(dispatcher, my_config) > > server.new_connection(dispatcher) > > ... # Anything else you need to do per connection > > end > > > > > > On top of this infrastructure we can create a variety of server classes > > that encapsulate a full stack and make it really easy to implement > > higher level services. It should be as easy to use something like an > > event based DRB implementation, for example, as it is to use the current > > synchronous one. > > This looks like just the sort of thing I want to do. (My > DRb server would be only one of several protocols I''d be > handling.) > > Note, I''m developing on Wind''ohs, and am currently using > EventMachine version 0.5.3. > > Should I be using a later version from SVN? I seem to have > formed the impression (possibly mistaken) that development > versions of EM might not yet be Windows-compatible, so I''ve > stayed with 0.5.3 so far. > > I am just getting acquainted with EM, and this DRb server > would be my first project using it. So any tips such as > "go ahead and develop with 0.5.3" or, "use a later SVN > version to take advantage of functionality XYZ" would be > appreciated. > > > Thanks! > > Bill > > > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk >
From: "Francis Cianfrocca" <garbagecat10 at gmail.com>> > Bill, use the latest snap.Hi, Following the instructions on the SCM Repository page on rubyforge for EventMachine, I did: svn checkout svn://rubyforge.org/var/svn/eventmachine But I''m puzzled by the resulting directory structure: branches branches/bayshore branches/bayshore/eventmachine experiments experiments/core-model-1 experiments/core-model-2 experiments/core-model-3 experiments/EventMachine experiments/io-reactor experiments/machine experiments/machine2 experiments/mixed-ruby experiments/NewMachine experiments/pure-ruby tags tags/eventmachine tags/eventmachine/eventmachine trunk trunk/CVSROOT trunk/eventmachine version_0 version_1 My first guess was trunk/eventmachine - but that contained only a README file. (I''m well versed in CVS but new to SVN....)> I''d like to hear more about how you''re attacking the DRb problem.Me too. :-) The part of the application I''m developing where I want to use DRb, is sort of a hub, to which any number of trusted plug-ins will connect over DRb, and provide services. Untrusted clients will also connect to the hub, _not_ using DRb, and will make use of the gestalt of available services. (via some as-yet undetermined protocol; I would use DRb for this, too, except DRb scares me for untrusted clients.) So, I envision using EventMachine in the hub, to: - provide a DRb server to which trusted plug-ins connect - make requests of any given plug-in over DRb (some of these requests will be driven by client requests; others will be triggered at certain times of day, ala cron) - provide a ??? (custom) server to which untrusted clients connect - service client requests, which will usually mean querying various plug-ins over DRb, then formulating a response for the client - push data to clients when events occur that clients care about My working assumption is that it should not be too hard to replace DRbTCPSocket with a new implementation that works with EventMachine... At least in terms of the basics of writing marshalled DRb data to the socket, and reading results back. But things start to get fuzzy when I wonder about the implications of being in the middle of servicing one request (say, a client request), and needing to go make a bunch of other requests (to plugins) before the answer can be computed. Will I be using something like ''defer'' to handle all my requests? Obviously I know too little about DRb and EventMachine, as yet... But it should be interesting...> One thing I''ve been thinking about adding is a user-defined message > capability. This would function exactly like message queueing. With a > persistence engine behind it, it would behave like assured-delivery > MQ. Might that be helpful for you?When I first read about EventMachine, I wondered if it would support any kind of user-defined message queueing. I can definitely imagine scenarios where user-defined messages might be useful. Maybe as I learn more about EM and DRb, I''ll have some more concrete ideas... Thanks, Regards, Bill
On 8/24/06, Bill Kelly <billk at cts.com> wrote:> From: "Francis Cianfrocca" <garbagecat10 at gmail.com> > > > > Bill, use the latest snap. > > Hi, > > Following the instructions on the SCM Repository page on > rubyforge for EventMachine, I did: > > svn checkout svn://rubyforge.org/var/svn/eventmachine > > But I''m puzzled by the resulting directory structure:The latest production-ready code is all in version_0. If you look there, you''ll see an orthodox Ruby-extension directory structure. All of the rest is a plethora of experiments toward richer functionalities in various states of completion. I''ll respond to your DRb thoughts a bit later.
On 8/24/06, Bill Kelly <billk at cts.com> wrote:> From: "Francis Cianfrocca" <garbagecat10 at gmail.com> > - provide a DRb server to which trusted plug-ins connect > > - make requests of any given plug-in over DRb > (some of these requests will be driven by client > requests; others will be triggered at certain > times of day, ala cron) > > - provide a ??? (custom) server to which untrusted clients connect > > - service client requests, which will usually mean > querying various plug-ins over DRb, then formulating > a response for the client > - push data to clients when events occur that clients > care aboutIn order to get the maximum performance from this architecture, you will want everything to be as nonblocking as possible. That includes requests that you make to trusted services on behalf of clients. I would look for a way to avoid using #defer in this case. Like Twisted''s Deferrables, #defer is really there to support locally-blocking stuff that you don''t have much control over, like database clients. (Although I would LOVE to see someone write an event-driven protocol handler for Postgres in pure Ruby. That would be awesome.) What''s interesting is that you''re talking about PRECISELY the application that EM was originally intended for. (I have a very long history with application architectures that are knit together with high-performance message queueing.) I can see the value of using DRb as one of the supported protocols, just because of its familiarity, but there are other approaches as well. (You may find this cryptic, but look a quick look at the Catamount project. Very little has yet been published, but a very large number of design points have already been worked out in this project.)