Hi,
We have been using CkSockets for about couple years on different systems (iOS, Windows, Android).

Due to new Apple's requirements (x64 version of application is must have for latest version of iOS) we were forced to upgrade our 9.4.0 version to 9.5.0.46 version on the iOS side. After changes of the syntax due to new interfaces we found out that all our functionality is broken with the latest version of CkSocket.

How do we usually used sockets?

We used synchronous sockets for communication. Async solution was implemented by using separate threads that access the same socket. For e.q. We have "ThreadReceive" for waiting and handling any data. In this thread we used "ReceiveBytesN" function. The time for waiting data is different from time to time. Sometime we can wait couple milliseconds and sometimes we can wait dozen of seconds. During waiting for data we should be able to send some messages through the same socket. For sending data we have another thread like "ThreadSend" and use there any "SendBytes" function.

On the version 9.4.0 everything worked perfectly. But after upgrade to 9.5.0.46 looks like the function "ReceiveBytesN" in thread "ThreadReceive" locks the socket for any other operations. We want to send data from "ThreadSend" while we are waiting for new data.

We tested similar functionality on different libraries (Mac, iOS, Windows) and results are the same. Socket is locked and we are not able to send data while waiting on "ReceiveBytesN" function.

We hoped that AsyncReceiveBytesN will not lock the socket, but unfortunately unsuccessful.

We only found such solution:
while (!pSocket->PollDataAvailable()) {
sleep(1);
} and allow to call "ReceiveBytesN" only if data is available.

As we are doing high performance communication between different parts of our application, we've got huge performance problems.

So the question: Is that correct behavior? or just a bug?

In case it is a new feature, how can we solve our problem (sending and receiving data from different threads at the same time). We wouldn't like to change the library, it is time consuming for development and very risky from QA prospective.

Bidirectional communication is ALSO SUPPORTED with the synchronous read/write methods, however, the Chilkat Socket object (CkSocket / CkoSocket) must remain thread-safe. This means that for a given CkSocket object instance, only one call at a time may be active. If one thread calls a method, the other will be blocked until the 1st thread's call completes.

The way to get around this is via the CloneSocket method (which was undocumented, and I'm sorry for that). The CloneSocket method returns a copy of the socket object that shares the same underlying TCP (or SSL/TLS) connection. Now each thread can have it's own object, and each object instance is thread-safe. You'll have to update your code to use CloneSocket.

Asynchronous calls don't have a need for CloneSocket because they return immediately while the read/write proceeds in a background thread.

The reference documentation will be updated (soon) and I also noticed that CloneSocket was not made available for .NET and ActiveX. With v9.5.0.47, CloneSocket will become available for those platforms.

Volodymyr, thanks for reporting the problem with highly-useful information. :)

It sounds like a bug to me. I'll work on the problem, but the work cannot begin until an ongoing task is finished, which may take another day. I'll post a download link when I have a new build for you to test.

The cloned socket is just another object instance that shares the same underlying TCP socket. If you close the socket from one CkSocket object instance, it's closed for the other -- because it's the same underlying socket..