Enhancement #31


Preliminary DNS Bot

Added by Marc Dequènes about 14 years ago. Updated over 13 years ago.

Bot :: MapMaker
Target version:
Start date:
Due date:
% Done:


Estimated time:
Patch Available:
Found in Versions:
Help Needed:


Orders to implement:
  • check presence of zone file
  • read entire zone file (adapt existing code)
  • write entire zone file (adapt existing code)

Support UNIX socket middleware backend only.

Related issues 2 (1 open1 closed)

Blocked by CyborgHood - Documentation #30: Establish a Preliminary inter-bot discussion protocolResolvedMarc Dequènes2010-04-05

Blocks CyborgHood - Enhancement #32: Adapt Postman to use Librarian and MapMaker BotsIn ProgressMarc Dequènes2010-04-05

Actions #1

Updated by Marc Dequènes about 14 years ago

  • Target version changed from 0.3.0 to 0.4.0
Actions #2

Updated by Marc Dequènes almost 14 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 40

After a few research and experimentations, i settled on EventMachine in order not to re-invent the wheel. The UNIX socket support is there, with a line-by-line text support, and adding an XMPP backend should not be too difficult.

Currently i focused on a base protocol, SMTP-like, which is not completely wired, and the link with objects. It is currently possible to navigate in a tree of virtual objects, and constructing it is now quite easy. Argument passing is ordered in a YAML sequence, to ease mapping with methods (one can still use named arguments with a single Hash parameter).

Also, the DNS class has been revamped completely.

What needs to be done now:
  • cleanup protocol handling (the Interface class should not know about anything on that level, sort out the SMTP-like codes, and document the protocol, rework commands replies too)
  • we need to create a session, linked to the connection and dying with it, to have instances of some objects keep a specific state over time (to be able to chain commands and have objects remembering the previous steps) (only needed for a few choosen classes, like Services::DNS::Zone)
  • test more the new DNS class
Actions #3

Updated by Marc Dequènes almost 14 years ago

A locking mechanism is necessary to ensure concurrent access don't tread on each other:
  • do not allow write when someone else has requested an exclusive access to the resource
  • delay read when someone is writing

A lock is released when the client ask for it, or when it leaves and his session is removed. It may be useful to care about long idle times and kick dead clients.

Actions #4

Updated by Marc Dequènes almost 14 years ago

  • % Done changed from 40 to 50

The session support is done. The DNS class has received many fixes. Several other fixes and improvements were made.

Clients generating too much errors are terminated now. Other connection checks, as well as locking would be made later and in another BR.

Actions #5

Updated by Marc Dequènes over 13 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 50 to 100

No locking yet, and several issues will be assigned to further releases.


Also available in: Atom PDF