Both products are excellent additions to your Visual Basic tool kit, so you should get them both. Both products come with sample programs to help get you started right away, so within a few moments after downloading a demo or the real deal, you can be on your way. IP*Works comes with several sample programs, including a web server application utilizing the IPDaemon control. Both products will work on Windows 95, Windows NT 3.51 and Windows NT 4.0. Also, there are no royalties for either product.

SnapSoft Web Control

       Great things do come in small packages, and SnapSoft's WEB32.OCX is no exception! It's a complete web server in a 104k OCX! It's as simple as dropping the web control onto a form and setting a few properties. It's incredibly fast, handles multiple threads, and does a lot of the work for you. For example, it will accept HTTP file uploads, basic authentication, cookies, and total control over HTTP headers. You can use it for simple tasks such as sending HTML or larger tasks such as file uploads or database access.

       SnapSoft's web control can also access ODBC data sources and form fields through its unique server-side HTML extensions (SHX). For those of you familiar with products such as Cold Fusion, iHTML or ASP, SHX will provide similar (limited) functionality to your application.

       The best part is performance. My tests showed a 5x speed improvement over Windows-CGI (a method commonly chosen by Visual Basic developers). With the same application, I was able to generate 1,200 requests per minute with the SnapSoft control versus 300 per minute using Windows CGI on a Pentium Pro 150 Mhz. The reason for the drastic improvement in performance is simple: no gateways, INI files, or the overhead of starting a Visual Basic application for each request. By having this control in your application, the web server runs in the same memory space as your application so there is no overhead!

       There are always drawbacks to something you have little control over. In the case of the SnapSoft web control, it's a commercially-distributed ActiveX control with no source code. You can assign values to properties and actions to events, but that's about it. Face it, you're at the mercy of the SnapSoft developers if you desire something it does not support. As with most small companies, SnapSoft consists of just a couple developers and probably a few other individuals to handle administration and support.

       While SnapSoft has done its best to make their web control powerful and flexible, there are certain things it cannot do:

1. Virtual servers (multi-homing)
2. Running the control on the same port as another web server and distinguishing which requests it should handle or ignore
3. Security, such as SSL
4. Support for new emerging technologies such as Active Server Pages (ASP).

devSoft IPDaemon Control

       Using SnapSoft's web control, you can have a drop-in web control for under $200, royalty free. The same goes for devSoft's IP*Works package, ringing in at $195. As I said earlier, both packages are highly recommended for your tool kit, and IP*Works is a great one to have around for your current and future projects. It comes in a Visual Basic version, an ActiveX version and a Delphi version.

       The control you would use for a web server in your project is the IPDaemon control. However, IP*Works comes with 14 other extremely useful controls worth mentioning:

• IPPort for basic client programming
• SMTP to send Internet mail
• UDPPort for UDP packet communications
• FTP for FTP client control
• IPInfo for DNS and other database functions
• NetCode for UUencode, Base64, and Quoted Printable encoding and decoding
• Rshell for execution of commands remotely on a UNIX machine
• ICMPPort for access to the IP control layer
• POP for Internet Post Office control
• Multicast, an Internet Multicast control
• HTTP for HTTP client programming (similar to the one that comes with VB5)
• NNTP for USENET news client programming
• Telnet for handling Telnet commands and Telnet negotiation
• Rexec for execution of commands remotely on a UNIX machine

       The 15th control which I intentionally did not list is called the IPDaemon control. The word "daemon" comes from the Unix world and refers to a server. It could just have easily been called "IPServer." This control can be used to create any kind of TCP/IP server. It can handle close to 1000 simultaneous connections on the same TCP/IP port (identified by a ConnectionID -- a number between 1 and 1000). It is designed to balance the load between connections for a fast, powerful server. IPDaemon's counterpart for client development is the IPPort control. Using IPDaemon, IPPort and perhaps the HTTP control, you could essentially develop your own web server and web browser in no time!

       You can take a look at the web page for IPDaemon to get more details about its properties and events, but what can it really do? How does it differ from the SnapSoft web control? For starters, the IPDaemon control merely handles the "dirty work" -- all of the low-level TCP/IP communication. Not very many people want to deal at that level, so for that task it does a great job. The difference between this control and the SnapSoft control is that you have to do more work. The benefit, of course, is that you have more control over your web server. If you want it to handle virtual servers, just program support for it! If you want it to do SSL, figure it out! You won't have to wait for another company to develop it for you.

       Luckily, along with the IPDaemon control you have 14 other controls to help you expand your web server. So, if you need to decode UUencoded data coming downstream you can plop in the NetCode control. Or, suppose you need to find your server's IP or host name. Try out the IPInfo control.

Performance

       My test lab for this performance test was a Pentium Pro 150 Mhz with 64MB RAM running Windows NT Server 4.0 (SP3). The same test was run on a Pentium Pro 200 Mhz with similar results. The following chart shows the performance of the two products mentioned above, and compares them to Windows-CGI (Using O'Reilly WebSite Pro).

       Test notes: Due to Windows-CGI's implementation, a 30ms delay was inserted between each request to allow the web server enough time to process the request from the CGI application. For all other tests, a 1ms delay was used.

Which Way Do I Go?

       It's always a trade-off between ease of use and flexibility. I've tried to accomplish two goals with this article:

1. Let you know that you aren't bound to other web servers if you want to write web server software
2. Let you know two different ways to accomplish the task of adding your own web server to your application, freeing you of ugly API calls and useless overhead.