dlecocq
commented
10 years ago You are right -- currently snappy, deflate and TLS are unsupported, but they are specifically called out when initializing a connection. I had a branch where I was hacking on TLS support, but was finding it difficult to support TLS from the mock server internal to the testing infrastructure. Some of the tests are already integration tests and so there's no reason for the TLS tests to not be -- I just haven't found the time.
I had been content putting it off, but with AUTH on the horizon we'll be prioritizing this work accordingly.
jehiah
@dlecocq I did an audit to understand how far away nsq-py is in terms of supporting nsq AUTH (added in bitly/nsq#356 and supported in other client libraries bitly/pynsq#72 bitly/pynsq#77 and bitly/go-nsq#35 bitly/go-nsq#43). I wanted to drop notes here for you as to what i found.
One item i noticed is that the identify response from nsq doesn't currently trigger snappy/tls socket upgrades. That needs to happen before the AUTH command is sent across. (auth will almost always require TLS). Because there are additional round trips involved in connection upgrade and AUTH there are some changes needed to adjust when that connection is "ready" and gets it's SUB sent across and added to the client/reader and marked as available.
The second part is that we adjusted clients so that they could be given a fully qualified path to lookupd with existing url parameters. This would allow lookupd to be specified as an SSL endpoint on an existing api platform, and would allow authentication information for lookupd to be embedded in the URL and the client would just add the topic parameter to any existing parameters.