Keesver

Checkout RemObjects Elements, you should be able to re-compile much of your Delphi code to .Net (Elements. Build native projects for any modern development platform, using the language(s) of your choice. Oxygene (Object Pascal), C#, Swift, Java, Go. | RemObjects Software).

Support for appinstaller is available since W10 (see Troubleshoot installation issues with the App Installer file - MSIX | Microsoft Learn). We have had issues in the past with the auto update feature (users had to restart their computer before the auto update would work) but that has been fixed by MS. 

47 minutes ago, Cristian Peța said:

More than 10% from 12500 installations in last year are Windows 7 and 8

We still support both update processes side by side having two separate installers. If you need to support W7 and W8 I think there is no way around this.

In the past we always did our own auto updating using a similar approach as presented here (rename exe, download new version, then restart). This works as long as the the application is installed inside the user profile, not when it gets installed in 'Program files'.

Nowadays we let Windows handle this using an MSIX installer accompanied by an .appinstaller file (you can configure auto update behavior from the appinstaller file). In my experience, using the .appinstaller gives a much better user experience than any other method.

Be careful with Mida. From my experience the software is not working. Although it can still be purchased, it won't run because at startup the software cannot contact their license server and then stops. I tried contacting the developer many times, never had a response.

I think this should work:

var F: IFoo;

Supports(DialogManager.CreateDialog(IMyDialog), IFoo, F);

Yes, works with FMX and VCL, but Windows only.

The first step would be to get more detailed 'crash' information. We use madExcept in all our software to do this (there are others too) which provides a solid stack trace when an exception occurs. Without such info you don't know what to look for....

In Citrix users are not allowed to start executables if they are not properly installed inside the system. Normally users are not allowed to install software themselves. So you should discuss with the hosting company if they can install your application into the Citrix image so that it becomes available to the users. If that is not an option, you can make your application available online using software like Thinfinity.

1 minute ago, Ian Branch said:

Tks.  I haven't had anything like that reported to me.

ok, good to hear, maybe our setup is different. We use a Windows 2019 datacenter, Gen 2 server.

We now have a single server running, but are moving into a load balanced multi server setup. Do you have any experience with this?

16 hours ago, Cristiam Azambuja said:

We used TSPlus Remote Access (https://tsplus-remoteaccess.com/?lang=en) and we are satisfied with the result.

This looks more like a remote desktop solution and needs local software. With Thinfinity we can access a single application from the browser on the remote server. There is not even a login process required.

Yes I mean Thinfinity, we have issues with starting new sessions, sometimes they will not launch (they hang on the 'loading' screen). We are working on this with them so I expect it to be fixed.

Hello,

Which solutions are available to virtualize Delphi applications so that it can be accessed from a browser?

We are currently using VirtualUI (https://www.cybelesoft.com/) but experience some technical issues. I wonder if alternatives are available.

Thanks for your tips and ideas

Kees

Quote

Is your answer that it is impossible (or very difficult) to create a stable android app using Delphi

To comment on this question,  we are using FMX and Delphi (11.1) to build a Windows/Android/IOS app. We are pretty satisfied with the support, development process and stability of the application. One source/multi platform works very well for us. See this link Lynx X - Apps op Google Play.

You are welcome to talk to our developers to share ideas or learn how we do stuff with Delphi 11.1

Yes, it works OK now.

Thanks for taking the time explaining the workings of Http and Indy. I have learned a lot over the past few days. I now have my reverse proxy working.

Greetings,

Kees

Remy, thanks for your comments again. I got it working now.

After adding extra logging I saw some strange behavior myself. RemObjects is sending 'keep-alive' messages and at some point the connection gets closed immediately after reading the POST request:

127.0.0.1:50782 Recv 8/17/2022 1:38:48 AM: POST http://service.a-dato.net:80/handler.ashx/binmessage HTTP/1.1
Host: service.a-dato.net
Keep-Alive: 300
Proxy-Connection: keep-alive
User-Agent: Remoting SDK
Content-Type: application/octet-stream
Content-Length: 17
Accept-Encoding: identity
Connection: keep-alive

R�R
ìF+F„�ò${n¼��
127.0.0.1:50782 Stat Disconnected.
Start call: 6 Port: 50782 Addr: 4437F28
Sent call: 6 Port: 50782 Addr: 4437F28

(See log file, line #190)
The log shows that port 50782 gets closed right after retrieving the POST request from the client, still CommandPassThrough is getting called which will then raise the 'Connection closed gracefully' exception. Doing some more testing, I found that the port gets closed here:

IdCommandHandlers.pas, line #507

	if LCommand.Disconnect then begin
        AContext.Connection.Disconnect;
      end;

I therefore updated TIdHTTPProxyServer.InitializeCommandHandlers and set Disconnect to False:

  LCommandHandler := CommandHandlers.Add;
  LCommandHandler.Command := 'POST';            {do not localize}
  LCommandHandler.OnCommand := CommandPassThrough;
  LCommandHandler.ParseParams := True;
  LCommandHandler.Disconnect := False; // <= Set to False

And....it works!!

Question:

• Should the command handler Disconnect?
• Are there any side effects to this change?

Full log file added again.

ProxyLog.txt

I do not know how that should work. Http requires that the remote server closes the connection to signal the call has completed. Forcing a CONNECT keeps the connection alive and breaks the flow between client and server. The client keeps waiting for the disconnect to happen, before completing a call to GET/POST.

I enabled all exceptions in Delphi and learned that a 'Connection closed gracefully' is raised during the communication, once this exception is raised, the communication hangs. Could it be that TIdHTTPProxyServer is re-using a closed socket? I have attached another log file that seems to prove it does. This logs ends with:

Reading call: 10
0.0.0.0:0 Stat Disconnected.

To investigate, I logged the address of the IdContext used in each call (inside the logfile shown as 'Start call: 8 Port: 49877 Addr: 3928120'). This shows that the connection used in call 10 was previously used in call 8. Call 8 succeeded, while 10 fails.

I tried setting TIdHTTPProxyServe.ReuseSocket to 'rsFalse' but this does not make a difference.

Hope this helps someone to understand the issue...

ProxyLog.txt

Hello again,

I have done some more testing and added extra logging to the proxy server:

    TIdTCPClient(LContext.FOutboundClient).Connect;
    try
      if Intercept <> nil then
        (Intercept as TIdServerInterceptLogBase).LogWriteString('Start call: ' + callno.ToString + #13#10);
      TransferData(LContext, LContext.Connection, LContext.FOutboundClient);

      Sleep(200);
      if Intercept <> nil then
        (Intercept as TIdServerInterceptLogBase).LogWriteString('Sent call: ' + callno.ToString + #13#10);

      LContext.Headers.Clear;
      LContext.FOutboundClient.IOHandler.Capture(LContext.Headers, '', False);
      LContext.FTransferMode := FDefTransferMode;
      LContext.FTransferSource := tsServer;
      DoHTTPResponse(LContext);

      if Intercept <> nil then
        (Intercept as TIdServerInterceptLogBase).LogWriteString('Reading call: ' + callno.ToString + #13#10);
      TransferData(LContext, LContext.FOutboundClient, LContext.Connection);
      if Intercept <> nil then
        (Intercept as TIdServerInterceptLogBase).LogWriteString('Done call: ' + callno.ToString + #13#10);
    finally
      LContext.FOutboundClient.Disconnect;
    end;

I have attached a logfile. In total 10 calls are made by the client. When the call succeeds, there is a message in the logfile saying 'Done: ' + call number. Calls 8 and 9 do not return a result, however call 10 does. Before a call is started there is a message indicating the connection is started (like 127.0.0.1:50376 Stat Connected.), however there are only 9 'Stat Connected' messages for 10 calls. Are connections re-used or does this indicate a problem with TIdHTTPProxyServer?

I also tried synchronizing the calls to the server by adding System.TMonitor.Enter(Self)/System.TMonitor.Exit(Self) at the start and end of method CommandPassThrough. This always causes a deadlock. I think this should work.

Questions:

• Is it logical that only 9 connections are started for 10 calls?
• How can I synchronize all calls to the server?

ProxyLog.txt

ProxyTest.zip

Hello Remy,

Thanks for taking to time to reply. The log shows that that every request receives a response, except the one highlighted. The log also shows that the first call to the server worked (that is calling LoginService.DomainCheck), trying to call the server a second time (re-using the same RemObjects channel) fails. I will do some more debugging to find out where it fails. Your clarifications are a good start starting points.

Greetings

Hello,

I'm using a TIdHTTPProxyServer component to create a proxy server for our application. Unfortunately the proxy server frequently blocks communication. As a test, I put a TIdHTTPProxyServer on a form and use this proxy i.c.m. with a call to a RemObjects server. I added an interceptor to log the output of the proxy component (see attachment). From this file I can see that the proxy server hangs on this call (see also attachment):

127.0.0.1:12719 Stat Connected.
127.0.0.1:12719 Recv 12/08/2022 15:59:26: POST http://service.a-dato.net:80/handler.ashx/binmessage HTTP/1.1
Host: service.a-dato.net
Keep-Alive: 300
Proxy-Connection: keep-alive
User-Agent: Remoting SDK
Content-Type: text/html
Content-Length: 17
Accept-Encoding: identity
Connection: keep-alive

}Ðm�BÐ�@�Fx8‘¯®V� (data is binary)

Comments:

• The first call to the server succeeds
• The problem comes on subsequent calls to the server (pressing 'Call service (8081)' multiple times)
• This problem only occurs when I use 'http' (using 'https' it works)
• It works when I use no proxy
• It works when I use another proxy (the second button will use Fiddler as a proxy server)
• When you run the test application, a logfile is written to 'c:\Temp\Log'

I have attached a test application to replicate the problem.

Thanks for your support and comments.

Kees

SimpleProxy.log

ProxyTestMain.zip

I purchased MIDA some time ago, it did what it had to do. Unfortunately it stopped working because the tool contacts a registration server at startup and this server has been down for a long time now (I think more than 2 years). I could never reach the developer/company behind MIDA.

There is another tool that can help out though: INNOVA Solutions - Delphi Code Converter - VCL Form to FireMonkey FMX Form

Sorry for bringing the bad news.

I have done some more testing and found that my setup fails because the proxy on the server tries to connect to the local proxy from a different port number/connection. This communication is (logically) blocked by the firewall. 

I thought this code made the server proxy communicate through the same channel as previously established between client and server:

    var tempIO := TIdIOHandlerStack.Create(AContext.OutboundClient);
    tempIO.OnBeforeBind := IOHandlerStack_BeforeBind;
    tempIO.ReuseSocket := rsTrue;
    tempIO.BoundPort := IdHTTPProxyServer1.Bindings[0].Port; <== Re-use outbound port from server to prevent blocking by firewall

Quote

On the client side, I would strongly advise you NOT to bind the TIdTCPClient and TIdHTTPProxyServer to the same local IP/Port at all.  Put the destination proxy server's IP/Port in the DEST command itself, and then have the receiving server extract the values from the command, not from the connected socket.  Then you can drop the TIdTCPClient connection after sending the DEST command, and even run the TIdTCPClient on a different PC if you wanted to.

I think this cannot work because the server proxy cannot reach the local proxy through the firewall. The connection between the two proxies must be initiated from the "inside".

This is what I'm trying to achieve:

Remote <x> Server proxy <x> local (reverse) proxy < > Internal network
'x' = firewall

1. local proxy opens connection with Server proxy
2. local proxy sends 'DEST commend' to register itself with Server proxy
3. Remote queries Server proxy for available clients
4. Remote sends 'REMOTE' command to server to to connect to a certain 'DEST'
5. Remote starts HTTP communication with given 'DEST' ==> here it failes because server proxy opens new channel to local proxy

Maybe my setup will never work and should I follow a very different path. Hints and tips more than welcome.

Greetings

Thanks for the tips, I'll try to implement them.

Update: It works when I turn off the Firewall on my internet router (one step forward). Apparently there are other ports/channels needed to make a HTTPProxy work? Investigating......

There is no error, the call from the remote server back into the client simply does not reach it's destination. The remote server does receive a HTTPBeforeCommand event, this line is being called on the server: 

Writeln('Command redirected to DESTINATION: ' + dest_ip + ' - ' +  dest_port.ToString);

The connection between client and server seems to be working. When I use telnet to connect to the server, I do get a response from the server when I execute the 'HELP' command. Similar the call to SendCmd('DEST') in our client returns '200 OK'. Also 'netstat' shows an active connection between client and server.

Maybe my question is: what do I need more that an active (TCP) connection between client and server? 

Does the HTTP Proxy server requires additional channels to be opened to make this work? Or should the single channel suffice?