Internet Pack for .NET

marc hoffman -

Let me spend a few minutes today on talking about our upcoming “Internet Pack for .NET” product, a low/medium level network framework for .NET that should be available soon.

Why “Yet Another TCP/IP Framework”, you may ask?

Well, Internet Pack was first conceived when we started to plan the upcoming RemObjects SDK 3.0 for .NET and were discussing what network layers to use and support. As you might know, the original RemObjects SDK was a product for Borland Delphi (and Kylix), and in the Delphi community, a couple of TCP/IP encapsulation layer are available, Indy – which is free and also distributed with Delphi in the box – being the most common one.

So naturally when we set out to develop RemObjects SDK for Delphi a few years back, we used Indy as a starting point and later expanded upon that by supporting additional commercial and non-commercial frameworks such as DXSocks (a subset of which was kindly donated to us to be included in the box), Synapse or WinInet (as well as a new and very fast and slick layer we’ll be introducing in an upcoming RO3/Delphi interim build – stay tuned).

On the .NET side, things weren’t that clear-cut.

Sure, a lot of third party IP frameworks for .NET are out there, but most of them are commercial and we did not want to force our users to use separate commercial libraries in addition to RO (although we surely will enable them to do so). Others – like Indy for .NET – were prohibitive from their footprint: a 2MB assembly for a TCP/IP layer was simply unacceptable for RO.

On the other hand, .NET already provides an encapsulation of basic TCP/IP socket access via its System.Net namespace that is much more elaborate than – say – the system-provided socket access under Win32 or Linux. Also, System.Net seemed to be fully supported and usable for Mono, the second biggest target platform for our .NET library. So it seemed tempting to just build RO on top of that.

Investigating deeper into what System.Net provided, it became clear that it was a great starting point to build from, but that it also left a lot to be desired in terms of usability, and that we’d end up writing a lot of code in RO that would not really be specific to RO, but could be reused in any internet application. We thought, hey, why not wrap this up in a nice layer that could be used for RO, but could also be made available to .NET developers who wanted to do general TCP/IP development? And thus – Internet Pack for .NET was born.

So we set out to develop Internet Pack (or IP, for short) as a thin layer on top of the Sockets support provided by System.Net. The goal was to provide encapsulation of the most common tasks people would perform with System.Net.Sockets anyway, while getting as little in the way of things as possible. As a result, writing an application (or a server or client protocol component) on top of IP will give you pretty much the same speed as if you were coding directly to the Socket class, while providing a whole lot of encapsulation and taking a lot of work – from simple things such as “open the server socket, wait for connections and spawn worker threads to process them” to highlevel tasks such as parsing and creating HTTP headers or handling the command/response dialog of protocols such as FTP or POP3 – off your shoulder.

So what’s in it for you?

What does Internet Pack offer at this time? What we currently have implemented, and will be available in the first release, are among others these features:

  • Server base component to encasulate multi-threaded server implementations.
  • Client base component.
  • Extensive HTTP Client and Server base component framework, including a fast and easy-to-work-with encapsulation of HTTP request/responses (the RO3 HTTP channel will be based on these).
  • Base components to encapsulate command/response based protocols such as FTP, NNTP or POP3, that allow you to very easily implement your own command based protocol components.
  • FTP client and server base components.
  • “VirtualFTP” server component with an easily extendible file system class hierarchy.
  • Extensible Connection class that can be (and currently is being) extended to support – say – SSL or other custom encryption or data processing.
  • SSL Connection using the commercial SecureBlackBox for .NET library

As indicated above, the power and flexibility of IP doesn’t specifically lie in what it does – let’s be honest, any other IP framework for .NET out there will support the features IP has for now – but in how it does it, and how easily it is to use and – more importantly – build upon.

Status

The IP project currently in its the last beta phase. We’ll have testers bang the product a few more days (or maybe a week), and are shooting for a public release before the end of the month (May 2004, that is ;-). Stay tuned for more infos – here or in our newsgroups.

Oh, and did i mention: “Internet Pack for .NET” will be available free of charge and with full source code (100% written in C#), and it will support .NET 1.1, 2.0 Beta, the Compact Framework and Mono Beta 1.

We are hoping that Internet Pack for .NET will be well received and widely used by the .NET community, and that over time the project itself will become a community effort. If you want to join in and help us extending IP – whether by providing a component implementation of the protocol of your choice, or by streamlining and extending the product core – don’t be shy and let me know!