On Sat, 2016-07-09 at 07:36 +0900, Faycal El Karaa wrote: > Hi Toby, > > Thanks for the feedback. > > Do you mean that the socket_engine has been removed after version > 0.12.2? > hmmm...this is not a viable solution because now it means that you > are > stuck with that version and can't benefit from bugs fixes, > improvements etc > from newer versions, right? > > I will have a look at it anyway, but it seems to me that as of today > qpid > proton has not been designed to be easily integrated in other io > frameworks, which is a pity.
It has, it has! That is presently my main goal for proton. The connection_engine is now stable in C++ and there is also one in C if you want to go lower down the stack. I am working on a libuv example at https://github.com/alanconway/qpid-proton/tree/c-libuv also there is an example of an epoll integration already in examples/cpp/mt/epoll_container.cpp I would love to help you get an ACE integration working, and hear your feedback on whether we need to make the integration easier. The idea is that proton does not provide *any* IO or threading code because the best way to do that depends on your framework. You don't need a socket from proton, you need to make a connection with ACE and then use a proton::io::connection::connection_engine to pump bytes from and to that connection in the most efficient way possible. The connection_engine provides buffers that you can read/write direct to minimize copying, or you can use Ace buffers and copy to/from the connectino_engine buffers if that works better. The connection_engine will parse the AMQP input data, turn it into event calls on a proton::message_handler (so your application code is the same as if you used the container) and fill the write buffer with resulting bytes for you to send via ACE. The socket_engine was an ease-of-use layer over the connection_engine that created a socket for you, but it turned out to too specific to the unix-like poll model, not so good for proactors like windows IOCP or libuv. If you find the connection engine difficult to work with directly, we could bring something like the socket engine back but I'd appreciate if you gave it a try. > One solution I can think of in my framework > for a qpid producer/publisher client is to create a specific ACE task > in a > separate thread and communicate with that task/thread with an ACE > queue > (each time a message is inserted into the queue, ACE will wake up the > ACE > task), that would be the easiest as I won't have to dig into qpid io > framework. But for a consumer client, I have to have some kind of > mechanism > to trigger an ACE event and from there call qpid proton....I will > have a > look at your solution, but it does not look very straightforward to > me, > maybe because the proton io interface is still a little bit obscure > imwo. Yep, I will be working on improving doc and making the interface easier - your suggestions appreciated. All you need to do in ace is push read data into the connection engine's read buffer and write data from the engines write buffer to the ace connection. Its your choice if you want to funnel all the proton activity into a single thread or handle each thread concurrently. > Also, as you mentionned, no security layers, which can be annoying as > well > as my app is communicating with a server that is abroad... The security stuff is not yet well addressed or tested for the connection engine, that will be fixed. It should not cause changes to the existing API, but might involve some additional calls. Please keep in touch, I want to get this working as well as possible so feedback from people using it is very important, and I may be able to clarify/fix things on the proton side. > > Cheers, > Faycal > > On Sat, Jul 9, 2016 at 1:42 AM, Tobias Duckworth <[email protected] > .com> > wrote: > > > Hi, > > > > I am also new to qpid-proton and needed to achieve a similar thing > > to you. > > > > I found the most recent releases 0.14 snapshot and 0.13.0 weren't > > very easy > > to interface with for the purposes you describe. > > > > I ended up using 0.12.2, which has a socket_engine > > (proton-c/bindings/cpp/include/proton/io.hpp). > > With this you can either get the socket engine to connect to your > > URL, or > > you can just provide the socket descriptor as a constructor > > parameter. > > Then you can 'drive' the engine either by calling the run() > > function on a > > thread (which isn't very useful for integrating into your own io > > framework), > > or by implementing the proton::handler interface in such a way that > > it is > > executed on the thread you wish to do the work on. > > > > It all works very nicely once you get it right, apart from I can't > > get any > > of the security layers to work at present, so no ssl or sasl yet. > > > > Good luck, > > Toby > > > > > > > > > > -- > > View this message in context: > > http://qpid.2158936.n2.nabble.com/Fwd-qpid-proton-integration-with- > > other-event-loops-i-e-QT-and-ACE-tp7647033p7647096.html > > Sent from the Apache Qpid users mailing list archive at Nabble.com. > > > > ----------------------------------------------------------------- > > ---- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
