event-driven networking

[Lenny G.]

Is there an event-driven network programming framework available in
Ruby? I'm looking for something like libasync (c/c++) or twistedmatrix
(python) that lets me respond to network or file-descriptor events in a
single-threaded (well, two-threaded if you count the event loop),
event-driven, callback sort of way.

I've been googling to try to find such a beast, but can't seem to
turn anything up. I'm new to ruby so it may be that its just so
natural to do event-driven network code in ruby that no one talks much
about it. After having experienced both libasync and twisted, there is
no other way I'd ever code up a protocol. Does something like this
exist, or has someone started creating something like it?

Thanks,
Lenny

 

[Lenny G.]

There was a similar thread a while ago, search for it in Google groups.
The response was "practically no". So if you are new to ruby and you know
twisted, why don't using it?

Okay, I think I see the thread.

So the reason this is important is that I'd like to do some Rails
work where the backend Ruby code implements a custom network protocol,
and I'd like for that to happen in an event-driven way.

Right now, the Python Rails equivalents don't really seem to be up to
snuff, so If I chose to do the whole thing in Python, I'd give up the
advantages of Rails.

Right now, the Ruby event-driven networking stuff doesn't seem to
exist, so if I choose to do the whole thing in Ruby, I'd give up the
advantages of that.

Do you know if anyone is writing an event-driven networking framework
for Ruby? That certainly seems like something that could be very
useful.

Lenny

 

[X-Man]

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

 

[Gene Tani]

AFAIK there's no Twisted (or nothing like that) in Ruby (one of the reason why
I'll not ever make the switch from Python)

but this must be a very entertaining or informative list, or something
in ruby caught your eye...

 

[cremes.devlist]

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.

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