Module: EventMachine

Defined in:
lib/eventmachine.rb

Overview

Introduction

EventMachine provides a fast, lightweight framework for implementing Ruby programs that can use the network to communicate with other processes. Using EventMachine, Ruby programmers can easily connect to remote servers and act as servers themselves. EventMachine does not supplant the Ruby IP libraries. It does provide an alternate technique for those applications requiring better performance, scalability, and discipline over the behavior of network sockets, than is easily obtainable using the built-in libraries, especially in applications which are structurally well-suited for the event-driven programming model.

EventMachine provides a perpetual event-loop which your programs can start and stop. Within the event loop, TCP network connections are initiated and accepted, based on EventMachine methods called by your program. You also define callback methods which are called by EventMachine when events of interest occur within the event-loop.

User programs will be called back when the following events occur:

  • When the event loop accepts network connections from remote peers

  • When data is received from network connections

  • When connections are closed, either by the local or the remote side

  • When user-defined timers expire

Usage example

Here’s a fully-functional echo server implemented in EventMachine:

require 'rubygems'
require 'eventmachine'

module EchoServer
  def receive_data data
    send_data ">>>you sent: #{data}"
    close_connection if data =~ /quit/i
  end
end

EventMachine::run {
  EventMachine::start_server "192.168.0.100", 8081, EchoServer
}

What’s going on here? Well, we have defined the module EchoServer to implement the semantics of the echo protocol (more about that shortly). The last three lines invoke the event-machine itself, which runs forever unless one of your callbacks terminates it. The block that you supply to EventMachine::run contains code that runs immediately after the event machine is initialized and before it starts looping. This is the place to open up a TCP server by specifying the address and port it will listen on, together with the module that will process the data.

Our EchoServer is extremely simple as the echo protocol doesn’t require much work. Basically you want to send back to the remote peer whatever data it sends you. We’ll dress it up with a little extra text to make it interesting. Also, we’ll close the connection in case the received data contains the word “quit.”

So what about this module EchoServer? Well, whenever a network connection (either a client or a server) starts up, EventMachine instantiates an anonymous class, that your module has been mixed into. Exactly one of these class instances is created for each connection. Whenever an event occurs on a given connection, its corresponding object automatically calls specific instance methods which your module may redefine. The code in your module always runs in the context of a class instance, so you can create instance variables as you wish and they will be carried over to other callbacks made on that same connection.

Looking back up at EchoServer, you can see that we’ve defined the method receive_data which (big surprise) is called whenever data has been received from the remote end of the connection. Very simple. We get the data (a String object) and can do whatever we wish with it. In this case, we use the method send_data to return the received data to the caller, with some extra text added in. And if the user sends the word “quit,” we’ll close the connection with (naturally) close_connection. (Notice that closing the connection doesn’t terminate the processing loop, or change the fact that your echo server is still accepting connections!)

Questions and Futures

Encryption: EventMachine needs the capability to run SSL/TLS on any of its clients and servers. Coming soon.

epoll(4): EventMachine currently is based on the select(2) system call in order to be compatible with the widest variety of platforms, but it would be interesting to re-base it on epoll(4). While requiring a Linux 2.6 kernel, this might possibly give much better performance and scalability. EventMachine’s C++ antecedents already work with kqueue from the BSD world, but it’s not yet clear that this is worth doing. Depends on how many people ask for it.

Would it be useful for EventMachine to incorporate the Observer pattern and make use of the corresponding Ruby observer package? Interesting thought.

Defined Under Namespace

Classes: Connection

Constant Summary collapse

VERSION = 
"0.5.3"

Class Method Summary collapse

Class Method Details

.add_periodic_timer(*args, &block) ⇒ Object

EventMachine#add_periodic_timer adds a periodic timer to the event loop. It takes the same parameters as the one-shot timer method, EventMachine#add_timer. This method schedules execution of the given block repeatedly, at intervals of time at least as great as the number of seconds given in the first parameter to the call.

Usage example

The following sample program will write a dollar-sign to stderr every five seconds. (Of course if the program defined network clients and/or servers, they would be doing their work while the periodic timer is counting off.)

EventMachine::run {
  EventMachine::add_periodic_timer( 5 ) { $stderr.write "$" }
}



255
256
257
258
259
260
261
262
263
264
265
 
# File 'lib/eventmachine.rb', line 255

def EventMachine::add_periodic_timer *args, &block
  interval = args.shift
  code = args.shift || block
  if code
    block_1 = proc {
      code.call
      EventMachine::add_periodic_timer interval, code
    }
    add_timer interval, block_1
  end
end

.add_timer(*args, &block) ⇒ Object

EventMachine#add_timer adds a one-shot timer to the event loop. Call it with one or two parameters. The first parameters is a delay-time expressed in seconds (not milliseconds). The second parameter, if present, must be a proc object. If a proc object is not given, then you can also simply pass a block to the method call.

EventMachine#add_timer may be called from the block passed to EventMachine#run or from any callback method. It schedules execution of the proc or block passed to add_timer, after the passage of an interval of time equal to at least the number of seconds specified in the first parameter to the call.

EventMachine#add_timer is a non-blocking call. Callbacks can and will be called during the interval of time that the timer is in effect. There is no built-in limit to the number of timers that can be outstanding at any given time.

Usage example

This example shows how easy timers are to use. Observe that two timers are initiated simultaneously. Also, notice that the event loop will continue to run even after the second timer event is processed, since there was no call to EventMachine#stop_event_loop. There will be no activity, of course, since no network clients or servers are defined. Stop the program with Ctrl-C.

require 'rubygems'
require 'eventmachine'

EventMachine::run {
  puts "Starting the run now: #{Time.now}"
  EventMachine::add_timer 5, proc { puts "Executing timer event: #{Time.now}" }
  EventMachine::add_timer( 10 ) { puts "Executing timer event: #{Time.now}" }
}



229
230
231
232
233
234
235
236
237
 
# File 'lib/eventmachine.rb', line 229

def EventMachine::add_timer *args, &block
  interval = args.shift
  code = args.shift || block
  if code
    # check too many timers!
    s = add_oneshot_timer interval
    @timers[s] = code
  end
end

.connect(server, port, handler = nil) ⇒ Object

EventMachine#connect initiates a TCP connection to a remote server and sets up event-handling for the connection. You can call EventMachine#connect in the block supplied to EventMachine#run or in any callback method.

EventMachine#connect takes the IP address (or hostname) and port of the remote server you want to connect to. It also takes an optional handler Module which you must define, that contains the callbacks that will be invoked by the event loop on behalf of the connection.

See the description of EventMachine#start_server for a discussion of the handler Module. All of the details given in that description apply for connections created with EventMachine#connect.

Usage Example

Here’s a program which connects to a web server, sends a naive request, parses the HTTP header of the response, and then (antisocially) ends the event loop, which automatically drops the connection (and incidentally calls the connection’s unbind method).

require 'rubygems'
require 'eventmachine'

module DumbHttpClient

  def post_init
    send_data "GET / HTTP/1.1\r\nHost: _\r\n\r\n"
    @data = ""
  end

  def receive_data data
    @data << data
    if  @data =~ /[\n][\r]*[\n]/m
      puts "RECEIVED HTTP HEADER:"
      $`.each {|line| puts ">>> #{line}" }

      puts "Now we'll terminate the loop, which will also close the connection"
      EventMachine::stop_event_loop
    end
  end

  def unbind
    puts "A connection has terminated"
  end

end # DumbHttpClient

EventMachine::run {
  EventMachine::connect "www.bayshorenetworks.com", 80, DumbHttpClient
}
puts "The event loop has ended"

There are times when it’s more convenient to define a protocol handler as a Class rather than a Module. Here’s how to do this:

class MyProtocolHandler < EventMachine::Connection
  def initialize *args
    super
    # whatever else you want to do here
  end

  #.......your other class code
end # class MyProtocolHandler

If you do this, then an instance of your class will be instantiated to handle every network connection created by your code or accepted by servers that you create. If you redefine #post_init in your protocol-handler class, your #post_init method will be called inside the call to #super that you will make in your #initialize method (if you provide one).

– EventMachine::connect initiates a TCP connection to a remote server and sets up event-handling for the connection. It internally creates an object that should not be handled by the caller. HOWEVER, it’s often convenient to get the object to set up interfacing to other objects in the system. We return the newly-created anonymous-class object to the caller. It’s expected that a considerable amount of code will depend on this behavior, so don’t change it.

Ok, added support for a user-defined block, 13Apr06. This leads us to an interesting choice because of the presence of the post_init call, which happens in the initialize method of the new object. We call the user’s block and pass the new object to it. This is a great way to do protocol-specific initiation. It happens AFTER post_init has been called on the object, which I certainly hope is the right choice. Don’t change this lightly, because accepted connections are different from connected ones and we don’t want to have them behave differently with respect to post_init if at all possible.



520
521
522
523
524
525
526
527
528
529
530
531
532
533
 
# File 'lib/eventmachine.rb', line 520

def EventMachine::connect server, port, handler=nil

  klass = if (handler and handler.is_a?(Class))
    handler
  else
    Class.new( Connection ) {handler and include handler}
  end

  s = connect_server server, port
  c = klass.new s
  @conns[s] = c
  block_given? and yield c
  c
end

.open_datagram_socket(address, port, handler = nil) ⇒ Object

EventMachine#open_datagram_socket is for support of UDP-based protocols. Its usage is similar to that of EventMachine#start_server. It takes three parameters: an IP address (which must be valid on the machine which executes the method), a port number, and an optional Module name which will handle the data. This method will create a new UDP (datagram) socket and bind it to the address and port that you specify. The normal callbacks (see EventMachine#start_server) will be called as events of interest occur on the newly-created socket, but there are some differences in how they behave.

Connection#receive_data will be called when a datagram packet is received on the socket, but unlike TCP sockets, the message boundaries of the received data will be respected. In other words, if the remote peer sent you a datagram of a particular size, you may rely on Connection#receive_data to give you the exact data in the packet, with the original data length. Also observe that Connection#receive_data may be called with a zero-length data payload, since empty datagrams are permitted in UDP.

Connection#send_data is available with UDP packets as with TCP, but there is an important difference. Because UDP communications are connectionless, there is no implicit recipient for the packets you send. Ordinarily you must specify the recipient for each packet you send. However, EventMachine provides for the typical pattern of receiving a UDP datagram from a remote peer, performing some operation, and then sending one or more packets in response to the same remote peer. To support this model easily, just use Connection#send_data in the code that you supply for Connection:receive_data. EventMachine will provide an implicit return address for any messages sent to Connection#send_data within the context of a Connection#receive_data callback, and your response will automatically go to the correct remote peer. (TODO: Example-code needed!)

Observe that the port number that you supply to EventMachine#open_datagram_socket may be zero. In this case, EventMachine will create a UDP socket that is bound to an ephemeral (not well-known) port. This is not appropriate for servers that must publish a well-known port to which remote peers may send datagrams. But it can be useful for clients that send datagrams to other servers. If you do this, you will receive any responses from the remote servers through the normal Connection#receive_data callback. Observe that you will probably have issues with firewalls blocking the ephemeral port numbers, so this technique is most appropriate for LANs. (TODO: Need an example!)

If you wish to send datagrams to arbitrary remote peers (not necessarily ones that have sent data to which you are responding), then see Connection#send_datagram.



589
590
591
592
593
594
595
596
597
598
 
# File 'lib/eventmachine.rb', line 589

def self::open_datagram_socket address, port, handler=nil
  s = open_udp_socket address, port
  klass = Class.new( Connection ) {
    handler and include handler
  }
  c = klass.new s
  @conns[s] = c
  block_given? and yield c
  c
end

.run(&block) ⇒ Object

EventMachine::run initializes and runs an event loop. This method only returns if user-callback code calls stop_event_loop. Use the supplied block to define your clients and servers. The block is called by EventMachine::run immediately after initializing its internal event loop but before running the loop. Therefore this block is the right place to call start_server if you want to accept connections from remote clients.

For programs that are structured as servers, it’s usually appropriate to start an event loop by calling EventMachine::run, and let it run forever. It’s also possible to use EventMachine::run to make a single client-connection to a remote server, process the data flow from that single connection, and then call stop_event_loop to force EventMachine::run to return. Your program will then continue from the point immediately following the call to EventMachine::run.

You can of course do both client and servers simultaneously in the same program. One of the strengths of the event-driven programming model is that the handling of network events on many different connections will be interleaved, and scheduled according to the actual events themselves. This maximizes efficiency.

Server usage example

See the text at the top of this file for an example of an echo server.

Client usage example

See the description of stop_event_loop for an extremely simple client example.

– Obsoleted the use_threads mechanism.



170
171
172
173
174
175
176
177
178
179
180
 
# File 'lib/eventmachine.rb', line 170

def EventMachine::run &block
#def EventMachine::run use_threads = true, &block
  @conns = {}
  @acceptors = {}
  @timers = {}
  initialize_event_machine
  block and add_timer 0, block
  #use_threads ? run_machine : run_machine_without_threads
  run_machine
  release_machine
end

.run_without_threads(&block) ⇒ Object

deprecated – EventMachine#run_without_threads is semantically identical to EventMachine#run, but it runs somewhat faster. However, it must not be used in applications that spin Ruby threads.



188
189
190
191
 
# File 'lib/eventmachine.rb', line 188

def EventMachine::run_without_threads &block
  #EventMachine::run false, &block
  EventMachine::run &block
end

.start_server(server, port, handler = nil) ⇒ Object

EventMachine::start_server initiates a TCP server (socket acceptor) on the specified IP address and port. The IP address must be valid on the machine where the program runs, and the process must be privileged enough to listen on the specified port (on Unix-like systems, superuser privileges are usually required to listen on any port lower than 1024). Only one listener may be running on any given address/port combination. start_server will fail if the given address and port are already listening on the machine, either because of a prior call to start_server or some unrelated process running on the machine. If start_server succeeds, the new network listener becomes active immediately and starts accepting connections from remote peers, and these connections generate callback events that are processed by the code specified in the handler parameter to start_server.

The optional handler which is passed to start_server is the key to EventMachine’s ability to handle particular network protocols. The handler parameter passed to start_server must be a Ruby Module that you must define. When the network server that is started by start_server accepts a new connection, it instantiates a new object of an anonymous class that is inherited from EventMachine::Connection, into which the methods from your handler have been mixed. Your handler module may redefine any of the methods in EventMachine::Connection in order to implement the specific behavior of the network protocol.

Callbacks invoked in response to network events always take place within the execution context of the object derived from EventMachine::Connection extended by your handler module. There is one object per connection, and all of the callbacks invoked for a particular connection take the form of instance methods called against the corresponding EventMachine::Connection object. Therefore, you are free to define whatever instance variables you wish, in order to contain the per-connection state required by the network protocol you are implementing.

start_server is often called inside the block passed to EventMachine::run, but it can be called from any EventMachine callback. start_server will fail unless the EventMachine event loop is currently running (which is why it’s often called in the block suppled to EventMachine::run).

You may call start_server any number of times to start up network listeners on different address/port combinations. The servers will all run simultaneously. More interestingly, each individual call to start_server can specify a different handler module and thus implement a different network protocol from all the others.

Usage example

Here is an example of a server that counts lines of input from the remote peer and sends back the total number of lines received, after each line. Try the example with more than one client connection opened via telnet, and you will see that the line count increments independently on each of the client connections. Also very important to note, is that the handler for the receive_data function, which our handler redefines, may not assume that the data it receives observes any kind of message boundaries. Also, to use this example, be sure to change the server and port parameters to the start_server call to values appropriate for your environment.

require 'rubygems'
require 'eventmachine'

module LineCounter

  MaxLinesPerConnection = 10

  def post_init
    puts "Received a new connection"
    @data_received = ""
    @line_count = 0
  end

  def receive_data data
    @data_received << data
    while @data_received.slice!( /^[^\n]*[\n]/m )
      @line_count += 1
      send_data "received #{@line_count} lines so far\r\n"
      @line_count == MaxLinesPerConnection and close_connection_after_writing
    end
  end

end # module LineCounter

EventMachine::run {
  host,port = "192.168.0.100", 8090
  EventMachine::start_server host, port, LineCounter
  puts "Now accepting connections on address #{host}, port #{port}..."
  EventMachine::add_periodic_timer( 10 ) { $stderr.write "*" }
}



412
413
414
415
416
417
418
419
420
421
 
# File 'lib/eventmachine.rb', line 412

def EventMachine::start_server server, port, handler=nil
  klass = if (handler and handler.is_a?(Class))
    handler
  else
    Class.new( Connection ) {handler and include handler}
  end

  s = start_tcp_server server, port
  @acceptors[s] = klass
end

.stop_event_loop ⇒ Object

stop_event_loop may called from within a callback method while EventMachine’s processing loop is running. It causes the processing loop to stop executing, which will cause all open connections and accepting servers to be run down and closed. Callbacks for connection-termination will be called as part of the processing of stop_event_loop. (There currently is no option to panic-stop the loop without closing connections.) When all of this processing is complete, the call to EventMachine::run which started the processing loop will return and program flow will resume from the statement following EventMachine::run call.

Usage example

require 'rubygems'
require 'eventmachine'

module Redmond

  def post_init
    puts "We're sending a dumb HTTP request to the remote peer."
    send_data "GET / HTTP/1.1\r\nHost: www.microsoft.com\r\n\r\n"
  end

  def receive_data data
    puts "We received #{data.length} bytes from the remote peer."
    puts "We're going to stop the event loop now."
    EventMachine::stop_event_loop
  end

  def unbind
    puts "A connection has terminated."
  end

end

puts "We're starting the event loop now."
EventMachine::run {
  EventMachine::connect "www.microsoft.com", 80, Redmond
}
puts "The event loop has stopped."

This program will produce approximately the following output:

We're starting the event loop now.
We're sending a dumb HTTP request to the remote peer.
We received 1440 bytes from the remote peer.
We're going to stop the event loop now.
A connection has terminated.
The event loop has stopped.



320
321
322
 
# File 'lib/eventmachine.rb', line 320

def EventMachine::stop_event_loop
  EventMachine::stop
end