On Thu, 2016-10-06 at 09:15 -0700, Tobias Duckworth wrote: > Thanks for your response - I started another thread on the 'Users' > list > (http://qpid.2158936.n2.nabble.com/qpid-proton-0-12-2-connection-engi > ne-remote-idle-timeout-td7651556.html) > > What's not clear to me from your response is why it works on a non > connection_engine build, but not on a connection_engine build. As a > result > of this I'm kind of expecting to find the calls I need to make within > the > CPP bindings, but have not found them so far. > > I'll have a go at doing as you suggest and translating the Go code > model > into C, but in the meantime could you satisfy my curiosity by > explaining why > it works for non connection_engine builds, but not for > connection_engine?
With pleasure, you may regret asking :) connection_engine isolates the "pure AMQP" codec and protocol state. This is "original proton" with a bytes-in/bytes-out API. Very embedable but not so simple to use, because the user must provide IO, polling and timers. The deprecated pn_messenger_t and current pn_reactor_t both take care of this for you. Ticking the transports is part of their poll loop. Our C++, python and ruby APIs use the reactor internally. Go doesn't so it has to tick for itself. The big problem with reactor and messenger is hard-coded assumptions of a single thread, posix-style sockets, cyrus SASL and openSSL. Those assumptions immediately broke for Windows and we had to re-write chunks of the reactor for schannel and IOCP. They broke again for Go which has its own concurrent connection management, TLS stack, and is definitely not single threaded. So the connection engine was born to allow concurrent processing of separate connections and a clean separation of protocol engine from the IO/threading environment that drives it. It is intended to be of use for embedding/integration work and longer term to replace the reactor in language bindings that can support concurrency and use language- native types and libraries for connection management. For C and C++ I am working on a multi-threaded driver framework. The goal is to be able to build the same (multi-threaded) application against different drivers for different platforms: libuv, posix and iocp are the initial targets. Meantime here's the complete set of things a driver needs to provide, the good news is you've already found most of them :) Essentials - initiating outbound connections - accepting remote connections - polling to feed bytes between IO and connection_engine - managing timers for transport ticks Security - configuring "external" encryption and authentication User tools: - user code schedule timed events using the driver. - multi-threaded user code communication between connection contexts --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
