All I/O is still synchronous, but the new design should make it easier to migrate to a truly asynchronous I/O model to improve I/O throughput (and allow single-threaded handling of multiple simultaneous commands without blocking while waiting for one to complete) in the future.
This is a big step closer to that design goal.
A page has been added to the MikroTik wiki for the Ruby API client:
http://wiki.mikrotik.com/wiki/API_Ruby_class
With careful application/use design, the 2.0 Ruby client can now handle commands that do not complete, but instead output a continual periodic response.
Example: Connect to a device and retrieve the list of current DHCP leases.
Code: Select all
require 'mtik.rb'
begin
tik = MTik.new(:host => '10.20.30.1', :user => 'admin', :pass => 'mypassword')
rescue MTikError, Errno::ETIMEDOUT, Errno::EHOSTUNREACH, Errno::ECONNREFUSED => e
print "ERROR CONNECTING OR LOGGING IN: #{e}\n"
exit
end
begin
tik.send_request(true, '/ip/dhcp-server/lease/getall') do |req, sentence|
## This code block ONLY gets called (it's a callback) when the command
## output completes with a '!done'...
## Iterate over each reply sentence:
req.reply.each do |reply|
if reply.key?('!re')
## Look at the DHCP lease info...
print "LEASE: mac=#{reply['mac-address']} IP=#{reply['address']} status=#{reply['status']}\n"
end
end
end
while tik.outstanding > 0
## Main "event loop"
tik.wait_for_reply
end
rescue MTikError, Errno::ETIMEDOUT, Errno::EHOSTUNREACH, Errno::ECONNREFUSED => e
print "ERROR during DHCP lease API request: #{e}\n"
exit
end
tik.close
Code: Select all
LEASE: mac=00:85:71:37:4F:26 IP=10.20.30.100 status=bound
LEASE: mac=00:1E:48:FE:1F:7E IP=10.20.30.103 status=
LEASE: mac=00:FF:44:08:43:E2 IP=10.20.30.105 status=
LEASE: mac=00:14:D2:F2:87:F0 IP=10.20.30.109 status=bound
LEASE: mac=00:19:BB:C9:82:FA IP=10.20.30.110 status=
LEASE: mac=00:0E:A3:BE:B3:AF IP=10.20.30.111 status=bound
LEASE: mac=00:25:C7:63:12:9A IP=10.20.30.108 status=bound
