Hi Arno
Thanks for the quick reply.
Setting the Clients SslContext obj property SslVerifyPeer = true yields
an errCode = 1 in the Clients HandshakeDone event (not a winsock error)
I tried setting up the clients SslContext::SslPrivKeyFile to the "C:\
... \ClientKey.pem" file created by the IcsSs
TIcsLogger.DoDebugLog uses non-optimal algorithm dealing with timestamps: it is
being added to Msg three times.
I suggest change the code as following:
procedure TIcsLogger.DoDebugLog(
Sender : TObject;
LogOption : TLogOption;
Msg : String); // remove const to avoid declarin
Anton,
> TIcsLogger.DoDebugLog uses non-optimal algorithm dealing with
> timestamps: it is being added to Msg three times.
I do not think that people use multiple log destinations at the
same time. Currently the string is allocated and concatenated
only when actually required.
> I suggest chang
Kurt,
> Setting the Clients SslContext obj property SslVerifyPeer = true
> yields an errCode = 1 in the Clients HandshakeDone event (not a
> winsock error)
>
> I tried setting up the clients SslContext::SslPrivKeyFile to the "C:\
> ... \ClientKey.pem" file created by the IcsSslBuildCerts.bat fil
Arno,
>I do not think that people use multiple log destinations at the
>same time. Currently the string is allocated and concatenated
>only when actually required.
But it's possible. My modification is more compact also.
>This is non-optimal as well.
>You always concatenate and allocate the strin
Anton,
>> I do not think that people use multiple log destinations at the
>> same time. Currently the string is allocated and concatenated
>> only when actually required.
>>
> But it's possible. My modification is more compact also.
Yes it is possible but rather unlikely IMO.
>> This is non-opti
