I think we are going to need to continue to support 1.1, as there are existing projects using it.
On 1/31/07, Tomas Restrepo <[EMAIL PROTECTED]> wrote:
As I mentioned in a previous email, now that a few initial patches I've submitted have been successfully integrated into the .NET client code in the trunk, I'd like to take a stab at adding SSL support to the .NET client. Is everyone OK with that? I've been looking at how best to approach this and I'd like to run a few things I've thought of by you. Any comments appreciated :) The first issue is that the .NET Framework v1.1 does not include any out of the box support for standalone SSL usage (it fully supports HTTPS, though). .NET v2.0 does support it through the System.Net.Security.SSLStream class, but we can't use it if we hope to maintain compatibility with v1.1 One possible replacement I've found is the Security Library from Mentalis.org (http://www.mentalis.org/soft/projects/seclib/). It's open source, though published under a custom license (http://www.mentalis.org/site/license.qpx), so someone would have to see if this is a problem. Once that is decided, we'd need to look at how to best implement this. I know the preferred model would be to keep the .NET client as similar to the Java client as possible, but the underlying connection and transport mechanisms in both clients are quite different at this level. Most of this is caused by the fact that the Java client IO and session mechanisms are based of MINA, while the .NET client doesn't have something similar (only a portion of the buffer management in mina was ported and implemented in Qpid.Buffer). That said, I do not feel we'd need to port MINA to .NET in order to implement any of this, but it would be nice to refactor the transport layer a bit to make it easier to implement [1]. Here's one possible proposal for this (very rough draft, as I haven't touched the code yet): - Make the ByteChannel (IByteChannel implementation) a bit of a higher-level construct. Right now, the ByteChannel is what hooks together the BlockingSocketProcessor with readers and writers on top of the transport (particularly with AmqpChannel), but it's a very thin layer and tightly coupled with the BlockingSocketProcessor class. I'm thinking we could do some fairly simple refactoring here that would decouple the ByteChannel and BlockingSocketProcessor, by moving the buffer management (ByteBuffer-related operations) in BlockingSocketProcessor into the ByteChannel and connecting both classes through a simple Stream interface. This would not only simplify the socket processor, but also make it easier to do the next step, which is to introduce filtering streams between the blocking socket processor (or any other potential processor introduced eventually when we tune the transport layer) and the ByteChannel. In particular, hook an SSL filtering stream to add SSL in the simplest manner (fairly simple to do with both .NET v2.0's SSLStream or Mentalis' SecureNetworkStream class). - Refactor the transport layer: besides the changes to the BlockingSocketProcessor and ByteBuffer classes mentioned above, I'd think that some refactoring of how the transport layer is initialized is needed. In particular, I'm thinking about the following: a- Improve how the transport is initialized, including handling it all the broker connection information (as that's what will contain the SSL connection requirements). b- Either formalize the transport -> processor relationship so that any transport layer is implemented in the same way, or remove the processor and have the transport class implement the socket operations directly. I'm not 100% happy about the second option, but another option would be to repurpose the processor classes so that they don't handle socket connection and only I/O (and maybe rename them to something more appropriate?). Besides this two big changes, I'm sure other minor stuff might be needed, but I'd take a look at it better when I'm doing the implementation. One thing I wouldn't do at first is add client-side certificates for SSL connections until the improved support for that (which Kevin Smith is working on) is committed into the Java server and client code and the authorization issue we discussed is more formalized. [1] One big difference here between the Java and .NET clients here, besides MINA, is that the Java client does a lot of stuff through the AMQProtocolHandler class, which doesn't exist in .NET yet. For example, this class does all Heartbeat operations, which in the .NET client are implemented directly (and I think partially only) in the AMQConnection class directly. I think that moving that stuff out of AMQConnection and possibly implement something similar to AMQProtocolHandler in the .NET client would be good, but there's a bit of stuff in there I haven't quite figured out yet as I'm not very familiar with MINA. I'd sure appreciate any comments on this issue! Tomas Restrepo [EMAIL PROTECTED] http://www.winterdom.com/weblog/
