HOME - - - - - Delphi Tutorials TOC - - - - - - - - - - - - Other material for programmers
    Delicious Bookmark this on Delicious   Recommend to StumbleUpon

"Blocking"/ "Non-Blocking"; "Asynchronous"/ "Synchronous"

... in the context of Piette's ICS for TCP/IP with Delphi and C++

This has good information, and a search button at the bottom of the page

Please don't dismiss it because it isn't full of graphics, scripts, cookies, etc!

More information about the source and format of these pages is available.


In a simple application, the user is pretty much in control, and things progress as rapidly has the user supplies input, or requests output.

When you start involving the internet, delays arise. The application may, for instance, request a web-page from a distant server, and it may be a few seconds (or more)... eons, in the terms that matter to the smooth operation of the internals of your system... before that web-page is sent back to the application.

Hold that thought.

Suppose you wanted the computer to introduce a 60 second delay before responding to a mouse click.

You wouldn't, I hope, use the following code, although in simple terms, it should work. (The code would go at the start of the OnClick handler, and 0.0007 of a day is about 60 seconds. When you do dtTime:=now; you put a number in dtTime which is the days and fractions of days since a date long in the past.

laMsgs.caption:='You must wait 60 seconds before I can comply';
dtClicked:=now;
repeat
until now=dtClicked+0.0007;
laMsgs.caption:='Thank you for waiting.';
//The code to do "it" would be put here

The reason you would NOT write any program that way is that the program would be "blocking"... it would tie up the system, waiting for the 60 seconds to pass. This is not the right way to do things when the underlying operating system is multi-tasking and event driven.

You must not create loops that the program will sit in for extended... in computer-time terms... periods of time. Doing so is called creating a "blocking" situation.

So what CAN you do?

The answer lies with events. There is a standard Delphi component called a Timer. If you haven't met it, you ought to read up about it. In a nutshell, for the hypothetical job we spoke about a moment ago, the programmer would solve the problem as follows...

A timer would be set up with an 60 second interval. The timer would not be enabled. When the user clicked the button concerned, the "Sixty seconds, please" message would be displayed, and the timer enabled. And that would be it for the OnClick handler! So how does what the button is supposed to do ever happen? The Timer has an event called "Timer". It will be raised when the timer has been running for however long the interval has been set for. The "Thank you for waiting", and code for what happens after the waiting period has passed goes in the OnTimer event handler. (And the application would also set the timer's "enabled" property back to false, unless you wanted what you had to wait a minute for to happen again and again, every 60 seconds.).

By using the timer, we've got around having something in the code that is "blocking". Almost as soon as the button is clicked, the computer has finished everything that is called for by the OnClick handler, and the system can go off and do other things. The timer, and the OnTimer event handler, take care of "picking up the thread", and executing the required code, when the time comes. In between the clicking of the button and the "Timer" event arising, the application is "doing nothing"... which is Good!

Returning to the world of TCP/IP and Piette's Internet Component Suite for Delphi....

If you had code that said....

Ask a remote server to send something
Repeat
  (do nothing)
Until the server's response arrives
Process the response

... you would be creating a "blocking" situation. An application designed to do things as above would also be called a "synchronous" application, as the operation of the system with the above code and the operation of the remote server would have to stay in step, would have to be synchronized.

There's a better way!

Rather like the "Click button/ wait 60 seconds/ do next stuff" example above, it is possible with ICS to split the "fetch / wait / process" up.

The THttpCli component is at the heart of what you need.

You prepare for an invocation of the "Get" method by filling various properties of your instance of the component. (We'll use an instance named HttpCli1 for our example.) You need, for instance, to fill HttpCli1.URL with the URL of what you want to fetch.

When you've prepared everything, you invoke the "Get" method.

There are certain exceptions which may arise, and which you should handle. The following comes from the OverByte demo "OverByteICSHttpTst"....

        try
            HttpCli1.Get;
        except
            Display('GET Failed !');
            Display('StatusCode   = ' + IntToStr(HttpCli1.StatusCode));
            Display('ReasonPhrase = ' + HttpCli1.ReasonPhrase);
            HttpCli1DocEnd(nil);  { This will close the file }
            Exit;
        end;

Now... I have to admit that I'm very much a "one eyed king" here... what follows may not be EXACTLY right... but I hope it will be close enough to set you on the path to success. Here, I am just trying to get the basic idea of non-blocking (aka asynchronous, i.e. "not needing synchronous operation) programming across to you. Elsewhere, I will take you more deeply into the code of OverByteICSHttpTst.

After the Get method of the HttpCli1 object has been invoked Things Happen, behind the scenes. Just as when the timer was enabled.

Various events (events... not exceptions. They are different) may be generated. One is generated when the document you are "Get"ing starts to arrive. Another when it finishes arriving. Another event arises when the request (the "Get") is done.

The things that need to be done at the different stages of the "conversation" with the remote server can be put in the event handlers for these different stages of the conversation, allowing you to hold the conversation... without resorting to any programming which would lead to blocking.

Hurrah! We are "done"! Sorry if it doesn't feel like it. Have a look at my tutorial about going into the OverByteICSHttpTst demo. And/ or read what some others have written on the blocking/ not-blocking issues....



The following is adapted from material at another supporter's site, http://www.mestdagh.biz/ics/help/. .... Begin Quote from mestdagh.biz....

At the heart of ICS are TWSocket and TWSocketServer components.
They encapsulates the winsock API, offering support for TCP,
UDP, and ICMP protocol.

The suite also has other higher level components, for things
like POP3, SMTP, FTP, HTTP, SOCKS, etc. All of these
components either use TWSocket or are derived from it.

Some of the components have a synchronous version (like
TSyncPop3Cli), while others have synchronous methods added.
However, the use of either of these is deprecated. It is
strongly encouraged to use the asynchronous version (like
TPop3Cli) or the asynchronous methods instead (see individual
help.)

Asynchronous means that a component is non-blocking; a method
call will return immediately while the component will do the
request in the background. When the request is done, an event
will fire indicating it.

Using synchronous approaches can lead to blocking.

End Quote from mestdagh.biz

There's further good information on blocking/non-blocking at...

http://users.telenet.be/sonal.nv/ics/faq/Frame_index.html

You'll have to navigate down to the "General/ Blocking or no" section.

---

Here's some of what's available at http://users.telenet.be/sonal.nv/ics/faq/Frame_index.html

:
Blocking vs NON-Blocking:

NON-Blocking:
Think of windows programming. It's event driven. Your program
doesn't hog the system or waste system time if no buttons are
being clicked on your program. But as soon as a button is
clicked then a message is sent to your app and then your app
does what it needs to do and then your app goes into hibernation
again. Pretty efficient and this is what's called "EVENT
DRIVEN". This event-driven way is also called NON-BLocking, and
the non-block way is also thought of as ASYNC way of doing
things. NON-Blocking is because if you had these lines:

Connect
GetFile
CloseConnection

The "Connect" function returns PRONTO without even making sure
it was completed successfully. So, then the next statement
"GetFile" would fail because it's trying to get a file when it
may not even be connected to the server yet :) And then the
CloseConnection happens and it probably fails as well :)

Event-driven instead:
So, you need to design your program like windows program. You
have the main app call a function and from then on you rely on
events. Just like ButtonClick and TComboChange and other events
in Delphi, these ICS components have events that allow you to
control the logical flow of stuff. So you may just have one
line:

Connect

And that's it. Then in the connect's FinishEvent, you would then
put one line of code that says "GetFile" and that's it, one
line. Then in the getFile's FinishEvent you stick one line that
says "CloseCOnnection" and that's it. Now I'm talking in fake
code here, but you get the idea. So, since you call one line of
code for each event, basically your program goes back to sleep
until the FinishEvent is triggered. It's a little more complex
but pretty much the case.

End quote from http://users.telenet.be/sonal....


I hope that has helped? If not, I can only suggest Google, or that you turn, as I said, to my detailed "messing" with OverByteICSHttpTst.

You WILL get the hang of it all!


            powered by FreeFind
  Site search Web search
Site Map    What's New    Search This search merely looks for the words you enter. It won't answer "Where can I download InpOut32?"

Click here if you're feeling kind! (Promotes my site via "Top100Borland")


If you visit 1&1's site from here, it helps me. They host my website, and I wouldn't put this link up for them if I wasn't happy with their service. They offer things for the beginner and the corporation.www.1and1.com icon

Ad from page's editor: Yes.. I do enjoy compiling these things for you. I hope they are helpful. However... this doesn't pay my bills!!! Sheepdog Software (tm) is supposed to help do that, so if you found this stuff useful, (and you run a Windows or MS-DOS PC) please visit my freeware and shareware page, download something, and circulate it for me? Links on your page to this page would also be appreciated!
Click here to visit editor's freeware, shareware page.

Link to Tutorials main page
How to email or write this page's editor, Tom Boyd


Valid HTML 4.01 Transitional Page tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.org


If this page causes a script to run, why? Because of things like Google panels, and the code for the search button. Why do I mention scripts? Be sure you know all you need to about spyware.

....... P a g e . . . E n d s .....