You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by Piotr Kliczewski <pk...@redhat.com> on 2014/03/28 11:56:08 UTC
Re: Protocol detection
Ken,
I use your sample and currently I am working on clean up code.
In my case the closure is initiated by the client and I close all links then connection and socket at the end.
When client socket is closed the server calls:
close_input function which invokes _pn_transport.close_tail()
After calling it I can see error message:
[0x7f79a4008d40]:ERROR amqp:connection:framing-error connection aborted
[0x7f79a4008d40]:ERROR[-2] connection aborted
Can you please advice how to get rid of it? I would like to close cleanly connection.
Thanks,
Piotr
----- Original Message -----
From: "Ken Giusti" <kg...@redhat.com>
To: proton@qpid.apache.org, "Saggi Mizrahi" <sm...@redhat.com>
Cc: "Piotr Kliczewski" <pk...@redhat.com>, "Barak Azulay" <ba...@redhat.com>
Sent: Thursday, January 23, 2014 3:24:00 PM
Subject: Re: Protocol detection
Hi Saggi
Sounds like you need to handle all the socket i/o directly, rather than having Proton do it "under the covers", right?
To do this, you'll need to avoid using the Driver and Connector and Listener classes from the Python binding - these classes perform all socket management and I/O, for those apps which want to let proton handle it.
What you'll need to do is use the proton Transport class to pass network data into and out of the Proton protocol Engine. There are no callbacks - you'll have to call into Proton, sending it bytes you've pulled from the network, and asking Proton if it has any data to send. You then have to perform the socket I/O yourself.
I've written some python code that does exactly that - you might find it a useful example. See:
https://github.com/kgiusti/fusion
And, specifically on how to do socket I/O, take a look here:
https://github.com/kgiusti/fusion/blob/master/python/sockets.py
The "connection" in the read/write_socket* methods in sockets.py is an instance of the Connection object from here:
https://github.com/kgiusti/fusion/blob/master/python/connection.py
Which contains an instance of the Proton::Transport. You can see how I use the Transport API to feed/read bytes to/from Proton.
Let me know if that helps,
Also, here's a couple of docs describing Proton's architecture and the engine model, if you're interested.
https://cwiki.apache.org/confluence/display/qpid/Protocol+Engines
https://cwiki.apache.org/confluence/display/qpid/Proton+Architecture
----- Original Message -----
> From: "Saggi Mizrahi" <sm...@redhat.com>
> To: proton@qpid.apache.org
> Cc: "Piotr Kliczewski" <pk...@redhat.com>, "Barak Azulay" <ba...@redhat.com>
> Sent: Wednesday, January 22, 2014 7:03:37 AM
> Subject: Protocol detection
>
> Hi, I'm from the VDSM project which is part of oVirt.
> We are in the process of adding multiple protocol support
> one of which is AMQP 1.0 though the proton library.
>
> We want to keep only requiring one port so our solution is
> to "peek" at the stream, detect the protocol and then pass
> it to the proper protocol implementation.
>
> So, in order to support SSL we have to do the SSL
> negotiation ourselves and pass read\write callbacks
> since we keep the SSL state of the session.
>
> We've been trying to get this to work with the proton-python
> bindings but there doesn't seem to be a way to pass our own
> read\write callbacks.
>
> Is there something were missing, is it something that's even
> planned\wanted?
>
> Thanks
>
--
-K
Re: Protocol detection
Posted by Ken Giusti <kg...@redhat.com>.
Hi Piotr, see comments in-line:
----- Original Message -----
> From: "Piotr Kliczewski" <pk...@redhat.com>
> To: "Ken Giusti" <kg...@redhat.com>
> Cc: proton@qpid.apache.org, "Saggi Mizrahi" <sm...@redhat.com>, "Barak Azulay" <ba...@redhat.com>
> Sent: Friday, March 28, 2014 6:56:08 AM
> Subject: Re: Protocol detection
>
> Ken,
>
> I use your sample and currently I am working on clean up code.
> In my case the closure is initiated by the client and I close all links then
> connection and socket at the end.
> When client socket is closed the server calls:
>
> close_input function which invokes _pn_transport.close_tail()
> After calling it I can see error message:
>
> [0x7f79a4008d40]:ERROR amqp:connection:framing-error connection aborted
> [0x7f79a4008d40]:ERROR[-2] connection aborted
>
> Can you please advice how to get rid of it? I would like to close cleanly
> connection.
>
So it looks to me like the connection close handshake isn't getting done. When you call close() on a link or a connection, the handshake doesn't occur immediately - in the case of the fusion api, that handshake won't occur cleanly until you've done all pending I/O and connection processing _after_ you call close().
I've recently updated the fusion code with quite a few bugfixes (and a couple of necessary API changes - sorry!). And I've been forced to change the name - it's no longer 'fusion' but 'dingus'. But I also added some simpler client examples which should clarify the close processing:
See https://github.com/kgiusti/dingus/blob/master/examples/python/send.py#L105 - the client closes both the sender link and the connection, but then runs a connection I/O+processing loop until the connection confirms that it has completely closed.
Take a look at the example connection processing code: https://github.com/kgiusti/dingus/blob/master/examples/python/utils.py#L76 - that processes the connection, and returns a boolean indicating if more work needs to be done. Typically, your main loop should call that processing code until it returns False.
And once all that is complete, the socket can be closed.
You should be able to avoid that connection error if your client's close logic works the same way. Let me know if that works for you, or if you hit any problems.
-K
> Thanks,
> Piotr
>
> ----- Original Message -----
> From: "Ken Giusti" <kg...@redhat.com>
> To: proton@qpid.apache.org, "Saggi Mizrahi" <sm...@redhat.com>
> Cc: "Piotr Kliczewski" <pk...@redhat.com>, "Barak Azulay"
> <ba...@redhat.com>
> Sent: Thursday, January 23, 2014 3:24:00 PM
> Subject: Re: Protocol detection
>
> Hi Saggi
>
> Sounds like you need to handle all the socket i/o directly, rather than
> having Proton do it "under the covers", right?
>
> To do this, you'll need to avoid using the Driver and Connector and Listener
> classes from the Python binding - these classes perform all socket
> management and I/O, for those apps which want to let proton handle it.
>
> What you'll need to do is use the proton Transport class to pass network data
> into and out of the Proton protocol Engine. There are no callbacks - you'll
> have to call into Proton, sending it bytes you've pulled from the network,
> and asking Proton if it has any data to send. You then have to perform the
> socket I/O yourself.
>
> I've written some python code that does exactly that - you might find it a
> useful example. See:
>
> https://github.com/kgiusti/fusion
>
> And, specifically on how to do socket I/O, take a look here:
>
> https://github.com/kgiusti/fusion/blob/master/python/sockets.py
>
> The "connection" in the read/write_socket* methods in sockets.py is an
> instance of the Connection object from here:
>
> https://github.com/kgiusti/fusion/blob/master/python/connection.py
>
> Which contains an instance of the Proton::Transport. You can see how I use
> the Transport API to feed/read bytes to/from Proton.
>
> Let me know if that helps,
>
>
> Also, here's a couple of docs describing Proton's architecture and the engine
> model, if you're interested.
>
> https://cwiki.apache.org/confluence/display/qpid/Protocol+Engines
> https://cwiki.apache.org/confluence/display/qpid/Proton+Architecture
>
> ----- Original Message -----
> > From: "Saggi Mizrahi" <sm...@redhat.com>
> > To: proton@qpid.apache.org
> > Cc: "Piotr Kliczewski" <pk...@redhat.com>, "Barak Azulay"
> > <ba...@redhat.com>
> > Sent: Wednesday, January 22, 2014 7:03:37 AM
> > Subject: Protocol detection
> >
> > Hi, I'm from the VDSM project which is part of oVirt.
> > We are in the process of adding multiple protocol support
> > one of which is AMQP 1.0 though the proton library.
> >
> > We want to keep only requiring one port so our solution is
> > to "peek" at the stream, detect the protocol and then pass
> > it to the proper protocol implementation.
> >
> > So, in order to support SSL we have to do the SSL
> > negotiation ourselves and pass read\write callbacks
> > since we keep the SSL state of the session.
> >
> > We've been trying to get this to work with the proton-python
> > bindings but there doesn't seem to be a way to pass our own
> > read\write callbacks.
> >
> > Is there something were missing, is it something that's even
> > planned\wanted?
> >
> > Thanks
> >
>
> --
> -K
>
--
-K