While I try to create an example software to show the different behavior,
would you care to explain me why are you changing the behavior of the base
class in the SSL socket?

I mean... if I don't want to use SSL (but SSL socket is forced on class
derivation), why we should have a different socket behavior that is
introduced on Do_FD_READ than just using the socket without USE_SSL active?

When you introduce the WSocket_Synchronized_WSAASyncSelect inside
Do_FD_READ for SSL without actually checking first if SSL is indeed
enabled, you are just changing how Do_FD_READ would work without USE_SSL,
effectively changing the behavior or the sockets since now every Do_FD_READ
will call WSocket_Synchronized_WSAASyncSelect then inherited DO_FD_READ
then WSocket_Synchronized_WSAASyncSelect again on Finally block, which it
would NOT happen if USE_SSL is deactivated.

I just want to understand why you have to change the base socket behavior
(making the socket behave differently if USE_SSL is enabled) for all
sockets (even if I don't want to use SSL).

If I want SSL activated it would be fine to have this behavior, but if I
don't need SSL why changing the behavior? All other messages
like Do_FD_WRITE, Do_FD_CONNECT, Do_FD_CLOSE and Do_FD_ACCEPT will check if
the socket is SSL enabled first, without adding any extra behavior to the
base class, only changing in case the socket is actually SSL

Thanks



On Tue, Nov 22, 2016 at 3:45 AM, Angus Robertson - Magenta Systems Ltd <
an...@magsys.co.uk> wrote:

> I have already previously investigated your problem and have been
> unable to reproduce it.
>
> I've explained previously why your fix is unacceptable.
>
> I have limited time for ICS, and need to spend it on development that
> benefits all ICS users, not just one.
>
> The only way I will look at this yet again is if you supply a very
> simple Delphi application that illustrates the problem and does not
> require any external libraries, ie copy all twsocket units needed to
> the application directory, create all components in code.
>
> It really would be so much easier if you rewrote your application to
> remove blocking modal dialogs from event handlers.
>
> Angus
>
>
> -------- Original Message --------
>
> *Subject:* Re: [twsocket] Compiling with SSL active changes socket
> behavior
> *From:* Éric Fleming Bonilha <e...@digifort.com.br>
> *To:* ICS support mailing <twsocket@lists.elists.org>
> *Date:* Mon, 21 Nov 2016 17:32:42 -0500
>
> 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
>
> --
> 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
>
-- 
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