https://projects.duckcorp.org/https://projects.duckcorp.org/favicon.ico?16699090422010-06-11T09:32:04ZDuckCorp ProjectsCyborgHood - Enhancement #31: Preliminary DNS Bothttps://projects.duckcorp.org/issues/31?journal_id=1102010-06-11T09:32:04ZMarc Dequènesduck@duckcorp.org
<ul><li><strong>Target version</strong> changed from <i>0.3.0</i> to <i>0.4.0</i></li></ul> CyborgHood - Enhancement #31: Preliminary DNS Bothttps://projects.duckcorp.org/issues/31?journal_id=1842010-08-15T03:43:59ZMarc Dequènesduck@duckcorp.org
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>40</i></li></ul><p>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.</p>
<p>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).</p>
<p>Also, the DNS class has been revamped completely.</p>
What needs to be done now:
<ul>
<li>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)</li>
<li>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)</li>
<li>test more the new DNS class</li>
</ul> CyborgHood - Enhancement #31: Preliminary DNS Bothttps://projects.duckcorp.org/issues/31?journal_id=1862010-08-15T18:51:42ZMarc Dequènesduck@duckcorp.org
<ul></ul>A locking mechanism is necessary to ensure concurrent access don't tread on each other:
<ul>
<li>do not allow write when someone else has requested an exclusive access to the resource</li>
<li>delay read when someone is writing</li>
</ul>
<p>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.</p> CyborgHood - Enhancement #31: Preliminary DNS Bothttps://projects.duckcorp.org/issues/31?journal_id=1872010-08-16T01:15:56ZMarc Dequènesduck@duckcorp.org
<ul><li><strong>% Done</strong> changed from <i>40</i> to <i>50</i></li></ul><p>The session support is done. The DNS class has received many fixes. Several other fixes and improvements were made.</p>
<p>Clients generating too much errors are terminated now. Other connection checks, as well as locking would be made later and in another BR.</p> CyborgHood - Enhancement #31: Preliminary DNS Bothttps://projects.duckcorp.org/issues/31?journal_id=3762011-03-03T23:27:07ZMarc Dequènesduck@duckcorp.org
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>50</i> to <i>100</i></li></ul><p>No locking yet, and several issues will be assigned to further releases.</p>