winntfs

As a Microsoft Storage MVP, I am always looking for ways to fill in the gaps between what Windows natively offers, and what seems to be useful for enterprise and consumer scenarios.

One intriguing product idea that I have built and have an advanced prototype running is a “Protocol Converter”. I am open to different names for the product since it really does not do justice to the myriad of use cases I can see. And I am sure some readers will point out even more use cases than I am missing at the moment. This is the first of a series of planned blogs around this “Protocol Converter” idea.

The “product requirements” as I set them include:

• Be able to freely convert any of CIFS, SMB2, SMB3, NFS to any of the other protocols. So in particular, be able to do all of these conversions

o   CIFS <-> SMB2, CIFS <->SMB3 CIFS <->NFS

o   SMB2 <-> CIFS, SMB 2 <-> SMB3, SMB2 <-> NFS

o   SMB3 <-> CIFS, SMB3 <-> SMB2, SMB3<->NFS

o   NFS <-> CIFS, NFS <-> SMB2, NFS <-> SMB3

• Develop this product with minimal resources
• Develop a highly maintainable product
• Develop a product with a very high probability of working with future protocol revisions such as SMB 3.1 or SMB 4.0 (imagined names). Of course, some testing and development may be needed depending upon what features these unknown protocols will have.
• Have an enterprise ready product, but of course, even such products begin life as a prototype

Figure 1 summarizes what this conceptual Protocol Converter looks like.

After reflecting on the product requirements for a while, I decided to write as little protocol specific code as possible. I have spent years developing CIFS & SMB 2/SMB 3 stacks, and while this work has been enjoyable, I decided the world does not need yet another implementation of any of CIFS, NFS, SMB 2 or SMB 3 protocol stacks. BTW I am extremely happy about the awesome SMB2/SMb 3 protocol stack that we have developed at www.HvNAS.com . It runs on any Linux/Unix and any CPU including Intel x86 and little endian CPUs. But back to the Protocol Converter, where a key observation is that Windows Server 2012 (and 2012 R2) already ship with all the protocol parsers I am looking for, both on the client and the server side! And that is what the prototype code leverages – as of now, it has zero protocol specific code!

I see three main phases in terms of code development for this project:

• Develop a “data path solution” where all data I/O for all protocol conversions works. So things such as file creation, deletion, enumeration, read, write, etc. work. This piece is already working, though it needs more testing.
• Develop a security solution that enforces enterprise class access control across multiple domains, etc. The “data path” solution does not enforce proper access control, but then again, this is just a product development milestone and not a shipping product yet!
• Add some protocol specific features that deal with differences between protocols e.g. deal with oplocks that exist on one side of the Protocol Converter, but not the other

I will write blogs to track progress on these additional development tasks as well as what I perceive to be use cases for this Protocol Converter.

I welcome any potential beta testers for this product.