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
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
Read from file
Write to 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
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.
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
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
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
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);
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.
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
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
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
- 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
- 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
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
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.