Would find it useful:ConnectionState

Jul 23, 2011 at 9:59 PM
Edited Jul 23, 2011 at 10:00 PM

Hi !

I've had a look into more internal details [sad to say, that this needs the VS'ObjectBrowser ;-) ] and I  see,
that there is info about the connection, but not it's state. Explained on the "Hello World" example,
the space - using TCP - will create a connection.

One of my other goals in my project is, to have a cache component, accessible over the wire.
If could post a Linq query and get a result, wich will be usually faster then re-querying the data
from it's ource [Sql, AD, etc.]. BUT: This would really only make sense, if I know - shortly or
immidiately before I post my query - that the remote space or it's connection is alive. Waiting for
a tcp timeout could really waste the caller time [which is only important, if there is some
interactivity as the root for that mentioned post].

I am not asking to have the space behave like a cache [this would be on my own], but if there
is a transport in use, which has state, the state should be accessible for further optimizations.
BTW:This would be useful for the jabber transport also.

Hope, I was clear. See it just as my wish for the future.

Best regards,


Jul 25, 2011 at 9:41 AM


Thank you for your suggestions. It is true that the tcp transport service internally stores information about all open connections, which could be made public over the XcoTcpTransportService class. Though I fear that this information still isn't 100% reliable, because if the connection to a remote space is lost, this is not immediately recognized, so you may still see the connection as "open" at your local space until it is recognized as closed (which will happen either when the next message is tried to be sent over this connection, or after 1 minute when the connection timeout occurs).

But I agree with you that in some cases this information may be interesting to access from outside. We'll think about how and what would make sense to make accessible.

Best regards

Jul 25, 2011 at 7:33 PM

Hi !

Thanks for your reply! One can count on you ;-)

Others also recommended keep-alive messages, which exactly fit here, I think. Dependend
on the required reliability, you could vary there timeout/interval. This gives a little predictability.


Jul 27, 2011 at 3:13 PM


Yes I would also suggest to use keep-alive messages, as they are more reliable than the socket state. I also use them in one of my projects, where a worker collects keep-alive messages from different sources and gives out warnings if some required worker has gone offline - works nicely.

Best Regards