image image Home   About   Downloads   Support   Links   Contact  
image
These articles and more are covered in more detail in Indy in Depth, the book exclusively about Indy. Get your copy today for as little as 29 Euros!





Copyright
2002 - 2013
Atozed Computer
Software Ltd.

image

Atozed Home  »  Indy Portal  »  Texts

Indy for Visual Studio.NET Developers

This article will cover some of the Indy basics, but is specifically geared towards Visual Studio.NET developers. It provides source code in C#, Visual Basic, and Delphi. It also answers some common questions from Visual Studio.NET users.

Indy is Sequential

Unlike most socket libraries, Indy is programmed sequentially. Its very much like reading or writing to a file. Typical file access might appear as follows:

Open file
Read from file
Write to file
Close file

Most socket libraries however do not treat sockets in the same manner and to perform these simple steps you would need to set up several events and coordinate their firings. Exceptions are handled the same was as files as well. If an exception occurs the method that was called will throw it instead of an event firing to signal the exception. This sequential style is more natural to developers and provides for easier development.

In Indy the code would be written sequentially and consist of:

Set host and port
Connect to server
Read from socket
Write to socket
Disconnect

Let's move to some real source code. NNTP is the protocol that is used for newsgroups. I will not cover it in detail in this article, but it like most protocols is text based. When a connection is made it responds with a greeting. It then waits for commands, and issues responses to those commands. For this demo, a connection will be made and then the QUIT command will be issued. If you are interested in NNTP, you should use Indy's NNTP class which implements the full protocol. For this demo a simple TCP client (TCPClient class) will be used instead as an introduction.

Make sure you have a connection to the Internet when you run these demos and that you are not firewalled from reaching our news server. Our news server will be used simply so you do not have to setup a server to test this client. Port 119 is used as this is the port that the NNTP protocol uses. Delphi source code in this first demo just for comparison. Further demos in this article will not include Delphi versions. These demos are console applications just to make things simple, they can just as easily be Winforms applications, ASP.net applications, or web services.

C#

Visual Basic

Delphi

You can see that Indy code is very straightforward. While this demo just demonstrates the basic TCP client, all of Indy's protocols work in similarly easy fashions. In this demo only the ReadLn and WriteLn methods were used, but using code insight or the Indy reference documentation you can see that Indy contains dozens of methods for both reading and writing various data types including arrays, numeric types, streams, and more.

You might notice that the Delphi version uses TIdTCPClient while the C# and Visual Basic versions use simply TCPClient. For the .net assembly Indy classes are renamed to conform to the .Net norms. Thus when using a Delphi reference, TId should be removed from any class names to make them usable in C# or Visual Basic.

HTTP Example

This article is not meant to discuss every aspect of Indy, merely provide a crash course for Visual Studio users. For a more in depth coverage please see the other Indy Demos and documentation. That being said I will present a basic HTTP example that retrieves a web page.

In this example a simple web page is retrieved and written to the console.

C#

Visual Basic

What are TIdStream and TIdStrings? Why do so many Indy methods use them and how can I use them in .NET?

Many Indy methods such at HTTP.Get accept TIdStream as an argument. Other methods accept TIdStrings. These classes are compatibility classes that allow Indy to be single source. Since Indy is single source across all platforms and predates the .NET framework.

These classes can easily be used from within .NET however. They can either be directly used by referencing them and calling their methods, or by using conversion from .NET types.

Conversion - C#

For C#, manual conversions are rarely necessary. Most conversions are done implicitly. Implicit conversion works by simply converting from the matching .NET class, into the Indy class automatically. So when an Indy method asks for a TIdStream, simply pass a FCL Stream, or any of its descendants. When an Indy method asks for a TIdStrings, pass a StringCollection. Other implicit type convertors exist as well, but these are the most common one.

Conversion - Visual Basic

Visual Basic does not support implicit conversions. For conversions in Visual Basic, try calling the constructor and passing the type you want to convert from as in New DestType(SourceType);

Using Streams

The Get method in the previous examples returned a string. However for binary files, or if you wish to output to a file, database or other stream based resource a different overloaded form of Get may be used as well. The following example demonstrates this.

C#

 

Other Common Questions

Since Indy is written in Delphi and still supports non .NET platforms such as Win32 and Linux, you may have noticed that Indy is different in a few places than most .NET libraries. This section will attempt to answer and address these questions.

What else can Indy do?

Lots more. Indy supports more than 120 Internet protocols and standards. If its a commonly used (or even infrequently), chances are that Indy supports it.

Why Delphi?

Indy has been around for more than 10 years now, and has been pure Delphi since 1995. .NET is the newcomer here, and while Indy now supports .NET as well, .NET is not the only platform is supports. C# does not support single source compilation for .NET , Win32, and Linux. Delphi does.

Why not port it to C#?

This is best summed up with the following points:

  • It Works - .NET is .NET. It doesnt matter if its written in Delphi. Does it matter to Visual Basic users that the FCL is written in C#?
  • Indy is Huge - Indy consists of a very large source code base (hundreds of units, hundreds of thousands lines of source code) and there is no need to mess with something that already works. If you are willing to port this massive code base the open source license supports it. However the compiled assembly will do the same as what Indy.Sockets .NET assembly already does. Its like asking for someone to manually translate the complete US Federal Register into Queen's English because you don't like the spelling in American English.
  • Continuing Development - Indy is developed by a very active team whose primary knowledge consists of Delphi.
  • Cross Platform - Indy has a very large user base (hundreds of thousands of developers) and we have no plans to abandon them. Porting to C# would create a code split and create a maintenance nightmare. Chances are you have already indirectly used Indy and you did not even know it. Did you know that Skype, Poco, and many other popular software packages use Indy?
  • The Indy Team likes Delphi - Plain as that. They have their reasons just as you have your reasons for using C# or Visual Basic. With .NET, everything works together so language is not an issue. Brits and Americans spell things differently, yet they can still speak to each other and even read what the other writes. Its the same for .NET.

More Demos

All demos discussed here can be downloaded in complete form from the Atozed Indy Demo Playground. The Atozed Indy Demo Playground also contains other more advanced demos. If you would like more in depth coverage, please check out Indy in Depth.

About the Author

Chad Z. Hower, a.k.a. "Kudzu" works for Atozed Software, and is the original author of both Internet Direct (Indy) and IntraWeb. Both Indy and IntraWeb have been licensed by Borland for inclusion in Delphi, Kylix and C++ Builder. Chad's background includes work in the employment, security, chemical, energy, trading, telecommunications, wireless, and insurance industries. Chad's area of specialty is TCP/IP networking and programming, inter-process communication, distributed computing, Internet protocols, and object-oriented programming. When not programming, he likes to cycle, kayak, hike, downhill ski, drive, and do just about anything outdoors. Chad, whose motto is "Programming is an art form that fights back", also posts free articles, programs, utilities and other oddities at Kudzu World. Chad is an ex-patriate who spends his summers in St. Petersburg, Russia, winters in Limassol, Cyprus, and travels extensively year round. Contact Kudzu.