# Event-driven networking **URL:** \ **Category:** ruby-talk\ **Created:** [24 January 2006 15:35 UTC](https://rubytalk.org/t/event-driven-networking/24270 "2006-01-24T15:35:34Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Tree\_Dweller](https://avatars.discourse-cdn.com/v4/letter/t/fbc32d/32.png) [@Tree\_Dweller](https://rubytalk.org/u/Tree_Dweller)\ **Post date:** [24 January 2006 15:35 UTC](https://rubytalk.org/t/event-driven-networking/24270/1 "2006-01-24T15:35:34Z")
Couldn't you use DRuby (require 'drb')? That's what I do in my Rails program. In the 2nd (distributed) server, I spawn a thread immediately upon request to the the work, and then return right away to the web process, which returns immediately to the browser. I don't have callbacks, but I imagine it would be dead-easy to have the 2nd server take a request ID from the 1st, then just call back using a DRuby call just like the 1st, pushing back the original request ID. This is the "asynchronous completion token pattern" as described by Schmidt. Here's the (very verbose) write-up ... [http://www.cs.wustl.edu/~schmidt/PDF/ACT.pdf](http://www.cs.wustl.edu/~schmidt/PDF/ACT.pdf) ---
**Author:** ![Alenpeacock](https://avatars.discourse-cdn.com/v4/letter/a/57b2e6/32.png) [@Alenpeacock](https://rubytalk.org/u/Alenpeacock)\ **Post date:** [24 January 2006 15:38 UTC](https://rubytalk.org/t/event-driven-networking/24270/2 "2006-01-24T15:38:42Z")
You certainly could use the asynchronous completion token pattern, but I think if you compared implmenting that vs. implementing it using an event-driven framework -- even using Schmidt's EMIS Management system example, you'd see that the event-driven framework is not only a lot less work, much less error-prone and easier to debug, but also higher-performance (of the three advantages, I actually consider the performance to be least important). I know that this type of proclamation sounds like pie-in-the-sky bigotry against well-established practices, but I'm not kidding: once you go event-driven, you never go back. If there is someone already working on a libasync equivalent in Ruby, I'd love to pitch in. If not, I'd love to think that I could start one up. Python's twisted is very nice, but they've implemented way up the stack. I'd settle for something as dead simple as a generic event-driven TCP/UDP programming framework.   Lenny ---
**Author:** ![Chuck\_Remes](https://avatars.discourse-cdn.com/v4/letter/c/3be4f8/32.png) [@Chuck\_Remes](https://rubytalk.org/u/Chuck_Remes)\ **Post date:** [24 January 2006 23:57 UTC](https://rubytalk.org/t/event-driven-networking/24270/3 "2006-01-24T23:57:02Z")
You might want to take a look at the Myriad framework [1] written by Zed Shaw. I'm not so sure it is fully functional because I believe it depends upon his Ruby/Event framework that he abandoned. Perhaps you'd want to continue his work. [1] [http://zedshaw.com/projects/myriad/index.html](http://zedshaw.com/projects/myriad/index.html) > **ยทยทยท** > > On Jan 24, 2006, at 9:38 AM, alenpeacock@gmail.com wrote: > > > You certainly could use the asynchronous completion token pattern, but > > I think if you compared implmenting that vs. implementing it using an > > event-driven framework -- even using Schmidt's EMIS Management system > > example, you'd see that the event-driven framework is not only a lot > > less work, much less error-prone and easier to debug, but also > > higher-performance (of the three advantages, I actually consider the > > performance to be least important). > > > > I know that this type of proclamation sounds like pie-in-the-sky > > bigotry against well-established practices, but I'm not kidding: once > > you go event-driven, you never go back. > > > > If there is someone already working on a libasync equivalent in Ruby, > > I'd love to pitch in. If not, I'd love to think that I could start one > > up. > > > > Python's twisted is very nice, but they've implemented way up the > > stack. I'd settle for something as dead simple as a generic > > event-driven TCP/UDP programming framework.