Class: EventMachine::Connection

Inherits:
Object
  • Object
show all
Defined in:
lib/eventmachine.rb

Overview

EventMachine::Connection is a class that is instantiated by EventMachine’s processing loop whenever a new connection is created. (New connections can be either initiated locally to a remote server or accepted locally from a remote client.) When a Connection object is instantiated, it mixes in the functionality contained in the user-defined module specified in calls to EventMachine#connect or EventMachine#start_server. User-defined handler modules may redefine any or all of the standard methods defined here, as well as add arbitrary additional code that will also be mixed in.

EventMachine manages one object inherited from EventMachine::Connection (and containing the mixed-in user code) for every network connection that is active at any given time. The event loop will automatically call methods on EventMachine::Connection objects whenever specific events occur on the corresponding connections, as described below.

This class is never instantiated by user code, and does not publish an initialize method. The instance methods of EventMachine::Connection which may be called by the event loop are: post_init, receive_data, and unbind. All of the other instance methods defined here are called only by user code.

Instance Method Summary collapse

Constructor Details

#initialize(sig) ⇒ Connection

:nodoc:



645
646
647
648
 
# File 'lib/eventmachine.rb', line 645

def initialize sig #:nodoc:
  @signature = sig
  post_init
end

Instance Method Details

#close_connection(after_writing = false) ⇒ Object

EventMachine::Connection#close_connection is called only by user code, and never by the event loop. You may call this method against a connection object in any callback handler, whether or not the callback was made against the connection you want to close. close_connection schedules the connection to be closed at the next available opportunity within the event loop. You may not assume that the connection is closed when close_connection returns. In particular, the framework will callback the unbind method for the particular connection at a point shortly after you call close_connection. You may assume that the unbind callback will take place sometime after your call to close_connection completes. In other words, the unbind callback will not re-enter your code “inside” of your call to close_connection. However, it’s not guaranteed that a future version of EventMachine will not change this behavior.

close_connection will silently discard any outbound data which you have sent to the connection using EventMachine::Connection#send_data but which has not yet been sent across the network. If you want to avoid this behavior, use EventMachine::Connection#close_connection_after_writing.



721
722
723
 
# File 'lib/eventmachine.rb', line 721

def close_connection after_writing = false
  EventMachine::close_connection @signature, after_writing
end

#close_connection_after_writing ⇒ Object

EventMachine::Connection#close_connection_after_writing is a variant of close_connection. All of the descriptive comments given for close_connection also apply to close_connection_after_writing, with one exception: If the connection has outbound data sent using send_dat but which has not yet been sent across the network, close_connection_after_writing will schedule the connection to be closed after all of the outbound data has been safely written to the remote peer.

Depending on the amount of outgoing data and the speed of the network, considerable time may elapse between your call to close_connection_after_writing and the actual closing of the socket (at which time the unbind callback will be called by the event loop). During this time, you may not call send_data to transmit additional data (that is, the connection is closed for further writes). In very rare cases, you may experience a receive_data callback after your call to close_connection_after_writing, depending on whether incoming data was in the process of being received on the connection at the moment when you called close_connection_after_writing. Your protocol handler must be prepared to properly deal with such data (probably by ignoring it).



742
743
744
 
# File 'lib/eventmachine.rb', line 742

def close_connection_after_writing
  close_connection true
end

#post_init ⇒ Object

EventMachine::Connection#post_init is called by the event loop immediately after the network connection has been established, and before resumption of the network loop. This method is generally not called by user code, but is called automatically by the event loop. The base-class implementation is a no-op. This is a very good place to initialize instance variables that will be used throughout the lifetime of the network connection.



658
659
 
# File 'lib/eventmachine.rb', line 658

def post_init
end

#receive_data(data) ⇒ Object

EventMachine::Connection#receive_data is called by the event loop whenever data has been received by the network connection. It is never called by user code. receive_data is called with a single parameter, a String containing the network protocol data, which may of course be binary. You will generally redefine this method to perform your own processing of the incoming data.

Here’s a key point which is essential to understanding the event-driven programming model: EventMachine knows absolutely nothing about the protocol which your code implements. You must not make any assumptions about the size of the incoming data packets, or about their alignment on any particular intra-message or PDU boundaries (such as line breaks). receive_data can and will send you arbitrary chunks of data, with the only guarantee being that the data is presented to your code in the order it was collected from the network. Don’t even assume that the chunks of data will correspond to network packets, as EventMachine can and will coalesce several incoming packets into one, to improve performance. The implication for your code is that you generally will need to implement some kind of a state machine in your redefined implementation of receive_data. For a better understanding of this, read through the examples of specific protocol handlers given elsewhere in this package. (STUB, WE MUST ADD THESE!)

The base-class implementation of receive_data (which will be invoked if you don’t redefine it) simply prints the size of each incoming data packet to stdout.



687
688
689
 
# File 'lib/eventmachine.rb', line 687

def receive_data data
  puts "............>>>#{data.length}"
end

#send_data(data) ⇒ Object

EventMachine::Connection#send_data is only called by user code, never by the event loop. You call this method to send data to the remote end of the network connection. send_data is called with a single String argument, which may of course contain binary data. You can call send_data any number of times. send_data is an instance method of an object derived from EventMachine::Connection and containing your mixed-in handler code), so if you call it without qualification within a callback function, the data will be sent to the same network connection that generated the callback. Calling self.send_data is exactly equivalent.

You can also call send_data to write to a connection other than the one whose callback you are calling send_data from. This is done by recording the value of the connection in any callback function (the value self), in any variable visible to other callback invocations on the same or different connection objects. (Need an example to make that clear.)



761
762
763
 
# File 'lib/eventmachine.rb', line 761

def send_data data
  EventMachine::send_data @signature, data, data.length
end

#send_datagram(data, recipient_address, recipient_port) ⇒ Object

send_datagram is for sending UDP messages. This method may be called from any Connection object that refers to an open datagram socket (see EventMachine#open_datagram_socket). The method sends a UDP (datagram) packet containing the data you specify, to a remote peer specified by the IP address and port that you give as parameters to the method. Observe that you may send a zero-length packet (empty string). However, you may not send an arbitrarily-large data packet because your operating system will enforce a platform-specific limit on the size of the outbound packet. (Your kernel will respond in a platform-specific way if you send an overlarge packet: some will send a truncated packet, some will complain, and some will silently drop your request). On LANs, it’s usually OK to send datagrams up to about 4000 bytes in length, but to be really safe, send messages smaller than the Ethernet-packet size (typically about 1400 bytes). Some very restrictive WANs will either drop or truncate packets larger than about 500 bytes.



789
790
791
792
 
# File 'lib/eventmachine.rb', line 789

def send_datagram data, recipient_address, recipient_port
  data = data.to_s
  EventMachine::send_datagram @signature, data, data.length, recipient_address, recipient_port
end

#start_tls ⇒ Object 



766
767
768
 
# File 'lib/eventmachine.rb', line 766

def start_tls
  EventMachine::start_tls @signature
end

#unbind ⇒ Object

EventMachine::Connection#unbind is called by the framework whenever a connection (either a server or client connection) is closed. The close can occur because your code intentionally closes it (see close_connection and close_connection_after_writing), because the remote peer closed the connection, or because of a network error. You may not assume that the network connection is still open and able to send or receive data when the callback to unbind is made. This is intended only to give you a chance to clean up associations your code may have made to the connection object while it was open.



700
701
 
# File 'lib/eventmachine.rb', line 700

def unbind
end