Hello all

Could someone take a more serious look at this issue I've reported in the
past???

This has become a huge issue for us because the TCustomSslWSocket is
CHANGING the behavior of base socket EVEN IF SSL IS NOT IN USE!!!

Today we got another issue that increased the processing of our application
to 100% of CPU usage because OnDataReceive is being called much more
frequently.

The whole problem is that Do_FD_READ(var Msg: TMessage) from
TCustomSslWSocket is changing the behavior of base socket


procedure TCustomSslWSocket.Do_FD_READ(var Msg: TMessage);
    BuffSize := (GSSL_BUFFER_SIZE * 2)-1;  { V8.27 size now configurable }
    SetLength(Buffer, BuffSize);

 { V8.22 moved here from Do_SSL_FD_READ  }
    WSocket_Synchronized_WSAASyncSelect({$IFDEF POSIX}Self,{$ENDIF}
         FHSocket, Handle, FMsg_WM_ASYNCSELECT, FD_WRITE or FD_CLOSE or
FD_CONNECT);
    try
    ...
    finally
       { V8.22 moved here from Do_SSL_FD_READ }
        WSocket_Synchronized_WSAASyncSelect({$IFDEF POSIX}Self,{$ENDIF}
          FHSocket, Handle, FMsg_WM_ASYNCSELECT, FD_READ or FD_WRITE or
FD_CLOSE or FD_CONNECT);
    end;



Before calling WSocket_Synchronized_WSAASyncSelect you MUST check if SSL is
active. Currently you are checking if SSL is active ONLY after TRY:

        if (not FSslEnable) or (FSocksState <> socksData) or
           (FHttpTunnelState <> htsData) then begin
            inherited Do_FD_READ(msg);
            Exit;
        end;

This chunk of code should be placed BEFORE
    BuffSize := (GSSL_BUFFER_SIZE * 2)-1;  { V8.27 size now configurable }

This way, if we are NOT using SSL socket, the base socket would behave
correctly, as it would simply call the inherited Do_FD_READ.

Right now, when Do_FD_READ is called it process
WSocket_Synchronized_WSAASyncSelect TWICE (Before, in the beginning of the
method and inside FINALLY) if we are NOT using SSL.

I have identified two critical issues with this behavior

First is the one I have already reported, that we cannot call a ShowModal
indirectly from OnDataAvailable because it would block all further socket
processing

Second problem we just identified today and created a HUGE issue with many
of our customers, because the application is now very unstable and using a
lot of CPU. We have identified that OnDataAvailable is called MUCH MORE
frequently than before

To solve the issues we are compiling ICS without SSL, but we will need SSL
soon, and if we activate SSL it will simply break our whole software
because you are changing the receive behavior of all sockets

Could someone please take this problem seriously and analyse the issue?

I can show you over a TeamViewer session the effects of this on our software


Thank you!

Eric Fleming Bonilha


On Wed, Aug 31, 2016 at 6:18 PM, Éric Fleming Bonilha <e...@digifort.com.br>
wrote:

> Angus
>
> Would you at least take a look at it again? Adding that line in SSL socket
> before actually checking if SSL is being used is changing the behavior of
> the base class and breaking compatibility
>
>
>> Not quite sure why the V8.22 change in wsocket made this change, but it
>> was an important bug fix that preventing ICS locking up on heavy
>> traffic, so very reluctant to change it.
>>
>> I think I saw this problem in one of my own applications a few days ago,
>> when a log window was opened, it's on my list to investigate.
>>
>
-- 
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to