🚀 go-pugleaf

"Peter" <piotrtrzeciak@yahoo.com> wrote in message 
news:47a369a7$1@newsgroups.borland.com...

> Shouldn't OnExecute be invoked only once per client connection?

No.  Most server code is written to loop its client handling, so the default 
behavior of OnExecute was designed to loop automatically for you so your 
handling code could be simplified.  This is also important for things like 
Indy's CommandHandlers, where the server has to handle the looping 
internally for you anyway, otherwise its internal handling breaks if you try 
to hook into it.  Also, in Indy 10, the connection handling is actually 
separated from the thread handling in order to support additional threading 
models (fibers, completion ports, etc), so you don't even have direct access 
to the actual thread anymore.

> 1. A clinet connects.
> 2. The listener thread spawns a new thred and executes OnExecute handler 
> in it.
> 3. Data exchange is performed within the OnExecute handler.
> 4. Either the client or the server closes the connection, and the thread 
> ends.
> 5. The listener thread spawns a NEW thread for a new connection.

All of that is exactly what TIdTCPServer actually does.  The only difference 
between what you understand and what Indy really does is in how #3 does its 
work.  Which do you think is easier for you:

1)
    procedure Execute(connection);
    begin
        while (not thread is terminated) and (connection is connected) do
        begin
            try
                repeat
                    read a command
                    process the command
                    send a reply
                until connection is disconnected;
            except
                disconnect connection
                terminate thread;
                exit;
            end;
        end;
    end;

2)
    procedure Execute(connection);
    begin
        read a command
        process the command
        send a reply
    end;

> As such, I assume there should be a clear OnConnect/OnExecute/OnDisconnect 
> sequence.

There already is, which is essentially as follows:

    try
        OnConnect;
        try
            repeat
                OnExecute;
            until Terminated;
        finally
            OnDisconnect;
        end;
    except
        Terminate;
    end

If you really want to do your own looping in OnExecute, you certainly can do 
that.  Simply disconnect the socket before exiting:

    procedure Execute()
    begin
        try
            while connected do
            begin
                read a command
                process the command
                send a reply
            end;
        finally
            disconnect
        end;
    end;

> If I'm coming into the OnExecute for the second time with the same 
> connection, how would I know where in the data I am?

Because you are supposed to exit the first OnExecute afte processing the 
first command, ready to process the next command when OnExecute is 
reentered, using the Data property of TIdPeerThread/TIdContext to persist 
any data you need between events (which you need to do anyway if you want to 
pass values between OnConnect/OnExecute/OnDisconnect.

> how would I force the connection to be dropped completely
> when at the end of the OnExecute method?

Just do so.  There is nothing stopping you from calling Disconnect() inside 
the OnExecute event.  The next time OnExecute is called, your 
reading/writing will raise an EIdConnClosedGracefully exception.  Simply 
allow that exception to escape back into the server (which you should be 
doing any EIdException-derived exception anyway) and it will release the 
socket and shut down the thread accordingly.

> the code inside of the if is always executed

Connected() can return true even if the socket is not actually connected 
anymore.  Most noticely, if there is still unread data in the connection's 
InputBuffer.  This is by design.

> I do not get the OnDisconnect handler every time.

OnDisconnect is not triggered until the thread is being shut down, whether 
the socket is still active or not.  That is the main reason why 
EIdException-derived exceptions must be allowed to reach the server's 
internal exception handlers, so it can track socket status correctly and 
manage the thread accordingly.  If you block the exceptions in your own 
exceptions handlers, the thread can continue to run endlessly until the 
server is deactivated.


Gambit