Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Chilkat

Pages: [1] 2 3 ... 7
I think keeping the connection long-term is the best way to go.  It might be a good idea to call imap.Noop once every few minutes when there is no activity.

Thanks.   Yes, I see the "C" headers for the Unicode (wchar_t) functions have this error.   Given that was just released in the last 2 days, I'll re-generate these headers and will re-publish..

I'll post here when finished.

I'll begin answering this question by describing the Chilkat thread safety, which will help in understanding the behavior.

Every Chilkat class is thread-safe in the following way:  If your application has multiple threads, and if each thread simultaneously calls the synchronousFullRequestNoBody method (or any method on the same object instance)  then only one thread at a time is allowed inside a method of a particular object.  The behavior is that one thread's call will run and all others will be blocked.  When the method call returns, another thread's call is allowed to pass, and so on.  All method calls will occur one after the other, but the order in which they are called is random.

Now consider the case where your application has one thread, and it calls the asyncrhonous FullRequestNoBodyAsync method (all on the same object instance), and calls Run for each.   The CkGlobal.MaxThreads property controls the max size of Chilkat's async (background) thread pool.  Assuming this is larger than the number of tasks started by calling Run, then all tasks will begin simultaneously.  However, now we are in the situation equivalent to what I described above.  When you call Run, it is the synchronous FullRequestNoBody method that is called from the background thread (managed by Chilkat).  Thus you have N threads each calling the synchronous Chilkat method all trying to gain access to the same object instance, and each will run one after the other but in a random order.

If you wish to run all HTTP requests simultaneously, then you would need each N CkRest objects, each with its own connection.  If you called Run for each, then you don't have the situation where N threads are tryinig to gain access to a single object.  Each thread has its own object and they all operate independently and simultaneously.

If you wish to run N HTTP requests, one after the other in a particular order using the same CkRest object instance, then you can do so using the CkTaskChain object.  (See the online reference documentation.)

What happens if I have one CkRest connection and generate two or more FullRequestNoBodyAsync CkTask's, and then start them all together with Run?

Will they be processed one after another in a queue?

General Discussion / Re: Licencing of CertStore
« on: April 29, 2018, 06:54:37 PM »
The CertStore class is one of the freeware classes. 

C / C++ / Re: CkPrivateKey->GetPkcs8Pem problem
« on: April 08, 2018, 01:32:02 PM »
Here's a 64-bit Linux pre-release:

(The number "463" is just a counter number to create a unique URL to avoid caching issues..)

C / C++ / Re: CkPrivateKey->GetPkcs8Pem problem
« on: April 08, 2018, 01:12:05 PM »
The fix will be in the next version.

If you tell me the version of MSVC, I can provide a pre-release build.  I'll create a Linux x86_64 build sometime today and will post the link here..

REST / HTTP / HTTPS / Re: S3 UploadBytes throwing error
« on: April 07, 2018, 12:18:02 PM »
Make sure to set both the AwsRegion and AwsEndpoint properties.
For example:

http.AwsRegion = "ap-southeast-2";
http.AwsEndpoint = "";

You can call GetReceivedData instead.

C / C++ / Re: CkPrivateKey->GetPkcs8Pem problem
« on: April 07, 2018, 12:06:16 PM »
Chilkat is providing the PKCS1 PEM.  I made the fix so that PKCS8 is produced.  If you would like a new build, please let me know the exact programming language, operating system, and anything else I'd need to know (.NET Framework, Java JDK version, Perl version, etc.)

REST / HTTP / HTTPS / Re: Request/retrieve post data from a webhook
« on: April 06, 2018, 11:21:58 AM »
You wouldn't use Chilkat to receive the information contained in the POST sent to your ASP page.  You would just use ASP for that.
In general, however your web page  is implemented (Classic ASP, ASP.NET, PHP, Perl, Python, Ruby, etc.) you would use that language's features to collect the incoming POST information.
At that point, you might use Chilkat, if appropriate, for anything.  For example, you might use Chilkat's JSON classes to parse the received JSON.

In Classic ASP, you might begin by examining the incoming data:


    for each x in Request.Form
        Response.Write("<br>" & x & " = " & Request.Form(x))


Digital Signatures / Re: Verify SMIME always succeeds
« on: April 03, 2018, 09:08:40 PM »
UwrapSecurity unwraps the encryption/signature layers and the resulting MIME is thus unencrypted and unsigned.  If UnwrapSecurity was successful, it would make no sense to call Verify afterwards because you no longer have signed MIME.  The Verify method verifies (non-recursively) the particular MIME part on which it is called.  You can call IsSigned to check to see if the MIME part is signed, and if so, then call Verify. 

(This problem was solved via private email.  The next version of Chilkat to be released will include the fix.)

Pages: [1] 2 3 ... 7