Delta V Software Forums

Thanks. I've imported the patch here and committed it.

This sounds a lot like some sort of connectivity issue on your network. Have you used telnet to verify that the clients have TCP connectivity to the server?

There may be a firewall getting in the way, or something like that.

Unfortunately I don't think this is likely. The pub/sub implementation currently maps quite closely to TCP, and extending it to something like PGM would be a lot of work.

I was eventually able to reproduce this... The assert is faulty - you can comment it out and rebuild, and it should be fine.

I haven't seen that before. I will see if I can reproduce it here.

On Windows you're probably better off using the default Schannel SSL implementation anyway. That will work even if your server is on a non-Windows OpenSSL-based platform.

Hi Ariel,

Can you send us a stack trace of the ASSERT?

Is your client process multithreaded? If so you'll need to make sure that only one thread at a time is using any given RcfClient<> object.

Hi Volker,

I've just imported the changes you previously attached - thanks for that. I will send you a patch you can apply to RCF 2.1 , just so you can verify that it works the way you expect it to. You will need to define RCF_USE_CLOCK_MONOTONIC in your build, for the changes to take effect.

Hi,

I suspect this may be due to multi-threading issues in the client side code. Can you send us some code of how you are establishing and maintaining client connections? It's important that only one thread at a time is accessing a RcfClient<> object.

The behavior here has not changed - you still need to use multiple RcfProtoChannel objects (one for each thread).

Thanks for the patch. This has been fixed in RCF 2.1.0.0 .