20030118

Welcome to the latest edition of Indy News!

Indy Book

Indy in Depth has been released and is available for immediate delivery!

Indy in Depth a book written by the Indy experts themselves. Indy in Depth covers from the very basic introduction to sockets all the way up to advanced usage. Whether you are an absolute beginner and have never programmed sockets before, or you are an advanced socket developer, Indy in Depth has material suited for you. Indy in Depth is authored by Chad Z. Hower a.k.a Kudzu (Original Indy Author and current Indy Project Coordinator) and Hadi Hariri (Indy Project Co-Coordinator).

There is also a companion book planned covering protocols and demos by Allen O'Neill (Demo Team Coordinator) and Don Siders (Documentation Team Coordinator).

Information on Indy in Depth is available at http://www.atozedsoftware.com/indy/Book/index.html.

New Demos

Several new demos have been posted and updated at the Indy Demo Playground. The Indy Demo Playground is available at the Atozed website at http://www.atozedsoftware.com/.

Eliza Web - HTTP Server example demonstrating the popular Eliza psychotherapy algorithm with a twist. Implements not only Eliza, but additional personalities such as Bill Clinton, and Microsoft Technical Support as well. Microsoft Technical Support is so real, you will not be able to tell the difference.

Remote BSOD Invocator - This demo invokes fake BSODs on colleagues machines. Choose from real ones, or BSOD haikus. Great office gag.

Speed Debugger - Speed debugger which is a demo that demonstrates the mapped TCP port component and also a custom IOHandler which purposefully limits the bandwidth of a connection. This allows connections to be minimized so as not to overload a connection, or simulate slow connections for debugging and simulating Microsoft IIS.

Thread Component - This demo shows how to use the visual thread component TIdThreadComponent.

Threaded SMTP Client - This demo shows how to send mail, as well as several different methods of updating the user interface from a thread.

Indy 10 Update

We are very actively working on Indy 10 and we hope soon to have some very exciting stuff to show you. For those of you that missed it, here is a newsgroup posting that I made in December about Indy 10.

Newsgroups: borland.public.delphi.internet.winsock
Subject: A peek at Indy 10
From: "Chad Z. Hower aka Kudzu" <cpub@hower.org>
Organization: Atozed Software
Date: Sat, 7 Dec 2002 23:23:18 -0500

As many of you know we disconnected the public access to Indy 10 a month or
two ago. This was because we were merging major changes and things were
going to be broken for a little while. We are not getting things back
together and will be opening back up soon. However Indy 10 will still be a
bit turbulent for a little while longer, but it will allow the academic and
the curious to begin looking.

I will be posting some articles as well as covering Indy 10 in Indy in
Depth (The book).

We've also had another unrelated issue cutting off public access. We have
switched our VCSs and do not have a process in place yet synchronizing an
FTP store for public access.

Ok enough background. A little future. Indy 10 is undergoing massive
structural changes to core. This will break some core code of users, but we
are trying to preserve as much protocol compatibility as possible. While at
times it may seem we are uncaring about the impact our changes have on you
as end users, this is not true. We evaluate each interface change and
weight the benefits and disadvatages. Changes that we make, we try to make
in a way that is easy to upgrade your applications with minimal effort. It
is the belief of the Indy Team that progress is not without some sacrifice,
and that through small changes to interfaces we can provide a much better
product instead of dragging along tons of vestigal baggage.

Indy 10 will have many expansions to protocols and extra features relating
to them. We have now split Indy packages and even teams for protocol and
core. Developers are free to work on both, but now each one is handled by
separate sub teams with unique managers.

I have removed myself to Core. I am still the Chair of Mercury Team (Admin)
and Indy Core (Development) but do not chair the protocols sub team. Im
still involved, but what this utimately means is that I am "removed" to
Core and mostly focusing on that part. Core consists of TCPClient,
TCPServer, etc.. While protocols consists of HTTP, FTP, yadda yadda. This
doesnt mean protocols is being neglected. Far be it - protocols has been
placed in good hands with other members who have proven their knowledge of
Indy, etc.

Because of this, most of what I am going to speak about now focuses on
core, which in turn of course affects protocols.

Core is undergoing a restructure to further abstract certain concepts. Just
as Winshoes to Indy 8 and then to 9 increased abstraction, so will 10. But
10 will take a bigger step than before.

In addidtion to this, Indy 10 as in previous upgrades will become more
scalable. But it will do it without making your code harder to implement or
write. You will still do things the Indy way.

In addition to expanding our threading "library" Indy 10 will contain
support for fibers. What is a fiber? Well in short, its a "Thread" but one
that is controlled by code - not the OS. You can run multiple fibers inside
of one thread, or run a single fiber across multiple threads (only one at a
time). It gets all pretty ugly but Indy handles all this for you. All Indy
components both clients and servers will support this, and in a mostly
transparent way.

Indy 10 will also contain support for multiple interfaces to the TCP layer
including Winsock (current), IO Completion Ports and Overlapped I/O. You
can choose simply by telling Indy which one to use. IOCP code is realy ugly
and Overlapped I/O is not very pretty either. But with Indy 10, you will
write Indy code just like you do now, and you wont have to deal with the
gory details.

The one scalability issue with Indy is with servers with more than 2,000
simultaneous connections. Very few servers fall into this category. Chat
servers, SMS, etc are two that fall into this category. These new models
will support these, but will also provide performance enhancements and
other benefits to HTTP and others.

My time is limited as always, especially since Im very active on Indy 10
again. I cannot promise to answer every question, or in detail. But
consider the discussion open, and I'll try to at least reply with quick
answers as I can.

And to close - here is a teaser. We are working on porting HTTP and others,
but here is an example of fibers using TCPClient to do HTTP until then.
Using this code a fiber is defined (THTTPFiber, see end) and then multiple
(2, 5, 50) etc are executed all at once - using ONE thread! The
HTTPTestFiber is a little messy, but soon this will be automatic for
servers and clients as well. It will be as easy as programming thread or
building servers is now in Indy 9. And soon there will be the ability to
schedule a given pool of fibers across a pool of threads. Fibers will
automatically be switched to the available thread for execution when they
are ready for execution.

So anyone interested in Indy 10? :)

procedure TformMain.HTTPTestFiber;
var
  i: Integer;
  LFiberWeaver: TIdFiberWeaver;
  LFibers: TList;
  LHTTPFiber: THTTPFiber;
  LSelfFiber: TIdConvertedFiber;
begin
  // All fibers MUST have a parent fiber. The parent fiber is the
  // fiber that gets "fallen back" on when all other fibers have finished.
  // A converted fiber is a special fiber, its a fiber that is created "out
of"
  // the current thread.
  LSelfFiber := TIdConvertedFiber.Create; try
    // The fiber weaver is a scheduler for the fibers. It schedules the
fibers
    // onto threads and
    LFiberWeaver := TIdFiberWeaver.Create; try
      // This is a list of fibers so we can destroy them later.
      LFibers := TList.Create; try
        // Create the specified number of fibers and add them to the
FiberWeaver
        for i := 1 to StrToInt(editFibers.Text) do begin
          LHTTPFiber := THTTPFiber.Create(LSelfFiber);
          with LHTTPFiber do begin
            FFiberWeaver := LFiberWeaver;
            FHost := Trim(editHost.Text);
            FDocument := Trim(editDocument.Text);
          end;
          LFibers.Add(LHTTPFiber);
          LFiberWeaver.Add(LHTTPFiber);
        end;
        // Run fibers. This will run all fibers until every fiber has run
and
        // completed. It will then return. In this case, all fibers will
run
        // under this thread.
        LFiberWeaver.ProcessInThisThread;
        // Free the fibers
        for i := 0 to LFibers.Count - 1 do begin
          TIdFiber(LFibers[i]).Free;
        end;
      finally FreeAndNil(LFibers); end;
    // Freeing causes AVs - trying to fix this now
    finally FreeAndNil(LFiberWeaver); end;
  finally FreeAndNil(LSelfFiber); end;
end;

procedure THTTPFiber.Execute;
var
  LHTTPResult: TStringStream;
  LIOHandler: TIdIOHandlerChain;
begin
  LIOHandler := TIdIOHandlerChain.Create(nil, FFiberWeaver, Self); try
    with TIdTCPClient.Create(nil) do try
      IOHandler := LIOHandler;
      Host := FHost;
      Port := 80;
      Connect; try
        Write('GET ' + FDocument + ' HTTP/1.0' + EOL + EOL);
        LHTTPResult := TStringStream.Create(''); try
          IOHandler.ReadStream(LHTTPResult, -1, True);
          with formMain.memoTest.Lines do begin
            Add(LHTTPResult.DataString);
            Add(EOL + '_____________________' + EOL);
          end;
          Inc(formMain.FReturnCount);
          formMain.UpdateLabels;
        finally FreeAndNil(LHTTPResult); end;
      finally Disconnect; end;
    finally Free; end;
  finally FreeAndNil(LIOHandler); end;
end;