On Thu, Nov 19, 2015 at 4:19 PM, Tom Boland <t...@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
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
