mORMot Open Source

It looks like your certificate file isn't signed by a valid CA or might be damaged.

server:
  HttpServer := TRestHttpServer.Create(HttpPort, [SampleServer], '+', useBidirAsync, 4, secTLSSelfSigned);
client:
  HttpClient := TRestHttpClient.Create('localhost', HttpPort, Model, true);

Congratulations to mORMot 2 for winning the championship with a time of 1.261s in the 1BRC in Pascal competition! mORMot is the best! Pascal is the best!

https://github.com/ObjectPascal-Communi … me-ov-file

Please try this PR: https://github.com/synopse/mORMot2/pull/319

There are two reasons for this issue:

1. No call to TSampleDaemon.Free()
2. Even if called, an exception will occur because Free() will call Stop(), and this function has already been executed in the previous CommandLine() when the user presses the Enter key.

Solution:

1. In the Stop() method, check the Server status and skip execution if it is not running.
2. Call TSampleDaemon.Free() at the end of the program.

If you try this commit: https://github.com/synopse/mORMot2/comm … c7a417d929, you will see that the server-side OnWSClose() can now be called regardless of whether the client is normally or abnormally disconnected, so that the TMyService.CallbackReleased() event inherited from TInterfacedObject or TInterfacedObjectRest will be called correctly.

Of course, there is no problem with your current approach, which allows for greater flexibility in handling disconnected events.

Maybe you call call Stop method first, then Start again.

You can take a look at the source code of the AfterServerStarted() method, and then you can manually control fServer.Route function. The core statement is :

    old := fServer.ReplaceRoute(new); 

Using https://github.com/jzebedee/LibDeflate.NET instead of zlib to Uncompress the data.

program demoUncompressString;
uses
  mormot.core.buffers,
  mormot.core.zip;

const
  b64Buffer = 'ZxsAA....==';
var
  binBuffer: RawByteString;
  xmlStr: RawByteString;
begin
  binBuffer := Base64ToBin(b64Buffer);
  xmlStr := UncompressString(binBuffer);
  ...
end.

It very simple task.

You can take a look at these posts first: https://synopse.info/forum/search.php?s … =252481331

mORMot can deal with such formatted JSON string. Here is demonstration code for using RecordLoadJson() to process it.

https://gist.github.com/zen010101/75acf … 1c7476285f

What does this sentence mean?
Is there any difference between the so-called "console of my test" and "///then, it calls the function TestThread"?
In "console of my test", did you also initiate the test using thread concurrency?

My suggestions are:

Server Side:
1. Output the `YourRestHttpServer.HttpServer.HttpQueueLength` property
2. Output the `TWebSocketServerRest(YourRestHttpServer.HttpServer).ThreadPool.WorkThreadCount` property (or using THttpServer(YourRestHttpServer.HttpServer).ThreadPool....)

Client Side:
1. Set global variable `HTTP_DEFAULT_RECEIVETIMEOUT := 120000`
2. Set  `YourRestHttpClientWebsockets.RetryOnceOnTimeout  := true`

Maybe AB has a easier solution with ClientRestoreCallbacks

In #2 floor, I mentioned one method:

      HttpServer.WebSocketsEnable(Server,PROJECT31_TRANSMISSION_KEY, false,
      [pboSynLzCompress], nil, Server.DoWSClose);

That is, inject the parameter aOnWSClosed: TOnWebSocketProtocolClosed in WebSocketsEnable();

In addition, there are two event properties in PWebSocketProcessSettings returned by WebSocketsEnable() that can also be used for your needs:

    /// callback run when a WebSockets client is just connected
    // - triggerred by TWebSocketProcess.ProcessStart
    OnClientConnected: TNotifyEvent;
    /// callback run when a WebSockets client is just disconnected
    // - triggerred by TWebSocketProcess.ProcessStop
    OnClientDisconnected: TNotifyEvent;
    /// if the WebSockets Client should be upgraded after socket reconnection 

Now that you have these events, they will be automatically called, and when the connection between the client and the server is abnormally interrupted, all you need to do in advance is to establish the correlation between the RemoteIP and the Callback 。

You should take a look at this example first: https://github.com/synopse/mORMot/blob/ … Server.dpr

The documentation for this example is here: https://synopse.info/files/html/Synopse … l#TITL_173

Content-Type is set to application/pdf, and Content-Disposition is set to inline, which tells the browser that the file should be opened directly in the browser rather than downloading it.

You can refer to this example:  https://github.com/synopse/mORMot/blob/ … Server.dpr

However, CallbackReleased can only be automatically triggered when the Client is closed normally (Interfaces are freed normally) and the network is ok. If it is due to abnormal reasons, such as the client program being killed by the OS, then this callback function will not be called.

I asked a similar question here:  https://synopse.info/forum/viewtopic.php?id=7037

After research, my solution is as follows:

First, create a subclass of TRestServer and add the callback function DoWSClose:

  TMyServer = class(TRestServerFullMemory)
  public
    procedure DoWSClose(Protocol: TWebSocketProtocol);
  end;
...
procedure TMyServer.DoWSClose(Protocol: TWebSocketProtocol);
begin
  Writeln('ConnectID: ', Protocol.ConnectionID, ' is closed. IP: ', Protocol.RemoteIP);
end;

In this callback function, you can obtain ConnectionID, RemoteIP and other information through Protocol parameters.

Second, pass in the new DoWSClose callback function in the WebSocketEnable method call:

  Server := TMyServer.CreateWithOwnModel([]);
  try
    Server.Server.CreateMissingTables;
    Server.ServiceDefine(TChatService,[IChatService],sicShared).
      SetOptions([],[optExecLockedPerInterface]). // thread-safe fConnected[]
      ByPassAuthentication := true;
    HttpServer := TRestHttpServer.Create('8888',[Server],'+',useBidirSocket);
    try
      HttpServer.WebSocketsEnable(Server,PROJECT31_TRANSMISSION_KEY, false,
      [pboSynLzCompress], nil, Server.DoWSClose).
        SetFullLog; // full verbose logs for this demo
...

Eventually, you will find that no matter what reason the Client disconnects from the Server, this callback function will be called. Of course, you need to bind the relationship between RemoteIP and Client Callback Interface and any other data you need to centrally manage in Join() or other similar Register() services. This way, when you are informed of the interruption, you gain control over handling the objects in the relevant list. Additionally, you should pay attention to thread-safety issues.

Even if optExecLockedPerInterface option is used when creating IChatService ?

    Server.ServiceDefine(TChatService,[IChatService],sicShared).
      SetOptions([],[optExecLockedPerInterface]). // thread-safe fConnected[]
      ByPassAuthentication := true;  

If the program has InterfaceArrayAdd(), then

intf := fConnected[i] 

will not report an error;
If you comment it out, an error will be reported.

Your explanation seems to be the exact opposite of what I stated.

This idea has it been realized yet?

Enjoy your time, recharge those batteries, and we'll see you soon with stories to share!

All works but TWinHttp.Get('https://z.cn', '', True{IgnoreTlsCertificateError}, nil, nil, 3000)) not, it seems not reading the RedirectMax property value.

Neither HttpGet('https://z.cn', ''); .

Real metal machine result: Ubuntu, Intel Core i5-1155G7 with 16G RAM

https://gist.githubusercontent.com/syno … tfile1.txt