[Twisted-Python] Implementing Postfix Inet Policy Check Client

exvito here ex.vitorino at gmail.com
Thu Nov 19 17:10:26 MST 2015


On Thu, Nov 19, 2015 at 4:19 PM, Tom Boland <tom at t0mb.net> wrote:

> Thanks again for this.  It's really useful.  It turns out that the
> delimiter is a plain old \n.  Who knows how consistent this will be between
> different policy daemons, I don't know!
>

I would check the Postfix docs for that.


> Now, this isn't a working example, it's just the minimum that will
> demonstrate my idea.  I just wonder if what I've done with the
> DeferredQueue is sane.  If I return the .get() entry from the DeferredQueue
> when doing the request, and then do a put() in lineReceived, am I
> guaranteeing that I will get my results in the correct order?
>

The DeferredQueue is a nice approach: it ensures the get() results come out
in the same order as the put() calls.

The key question is whether or not the server handles multiple outstanding
requests within the same connection. Given your informal protocol
description, if the server supports it, it seems the responses must come
back in the same order as the requests were sent, otherwise there is
apparently no way to relate them; that being the case, what's the advantage
of pushing more than one request at a time if one slow request/response
"transaction" will delay a subsequent fast request/response "transaction"?

A variation of this, assuming the server only handles one outstanding
request at a time per connection, could be a protocol implementation that
would queue requests ensuring only one was sent at a time: this might
provide a cleaner client side API.

PS: My references to "Postfix docs" might need to be replaced by "your
policy server docs" which, hopefully, will match Postfix's... (you would
know that) :)

Cheers,
--
exvito
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20151120/3ee25ae2/attachment-0002.html>


More information about the Twisted-Python mailing list