Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Subscription initial event gets NetworkTimeout
07-04-2017, 10:34 AM (This post was last modified: 07-04-2017 10:35 AM by simoncn.)
Post: #1
Subscription initial event gets NetworkTimeout
I have been investigating a problem where a client subscribes to a service and the service's attempt to send initial property states and the initial event message to the client fails with a NetworkTimeout error after 3 seconds.

After this, the service takes no further action. The client has not received the initial property states and waits (forever) for this to happen. There are no property updates on the service side, so the service doesn't try to send any more messages to the client. The client continues to renew the subscription successfully, so there is connectivity in this direction.

Would it be possible/reasonable for ohNet to detect at the client end that the initial event was not received and return an error to the application? Or should the client application wait 3 seconds and take action if the initial event has not been received in that time? Where does the 3 second timeout come from and will this be the same on all platforms?
Find all posts by this user
Quote this message in a reply
09-04-2017, 01:24 PM
Post: #2
RE: Subscription initial event gets NetworkTimeout
I have implemented retry logic in the client application and this seems to be working OK. If the InitialEvent notification isn't received within 4 seconds, the client unsubscribes and resubscribes. This repeats indefinitely until an InitialEvent is received. So far, the longest delay I have seen is just over 8 seconds (reason unknown).
Find all posts by this user
Quote this message in a reply
12-04-2017, 03:11 PM
Post: #3
RE: Subscription initial event gets NetworkTimeout
(07-04-2017 10:34 AM)simoncn Wrote:  I have been investigating a problem where a client subscribes to a service and the service's attempt to send initial property states and the initial event message to the client fails with a NetworkTimeout error after 3 seconds.

After this, the service takes no further action. The client has not received the initial property states and waits (forever) for this to happen. There are no property updates on the service side, so the service doesn't try to send any more messages to the client. The client continues to renew the subscription successfully, so there is connectivity in this direction.

Would it be possible/reasonable for ohNet to detect at the client end that the initial event was not received and return an error to the application? Or should the client application wait 3 seconds and take action if the initial event has not been received in that time? Where does the 3 second timeout come from and will this be the same on all platforms?

Notification of failed subscriptions has been on my todo list for a while. I'll try to get some time scheduled for this.

Assuming the device being subscribed to is running ohNet, the 3 second timeout comes from TcpConnectTimeout set in InitialisationParams for the device stack.
Find all posts by this user
Quote this message in a reply
12-04-2017, 07:10 PM
Post: #4
RE: Subscription initial event gets NetworkTimeout
Thanks! I know how the todo list thing goes. Sad

The device being subscribed to will always be running ohNet in my scenario.

The problem with NetworkTimeout is not occurring at present. I had been hoping to test what happens if the client unsubscribes and resubscribes while the server is stuck in its 3-second wait. Would you expect the server to handle this correctly?
Find all posts by this user
Quote this message in a reply
13-04-2017, 07:57 AM
Post: #5
RE: Subscription initial event gets NetworkTimeout
(12-04-2017 07:10 PM)simoncn Wrote:  The problem with NetworkTimeout is not occurring at present. I had been hoping to test what happens if the client unsubscribes and resubscribes while the server is stuck in its 3-second wait. Would you expect the server to handle this correctly?

Yes, this should be fine. Internally, I'd expect the control point stack thread that sends the unsubscribe request to block until the device stack completes or fails its initial event. Externally, client code won't notice any problem - the public unsubscribe API will still complete immediately.
Find all posts by this user
Quote this message in a reply
13-04-2017, 02:07 PM
Post: #6
RE: Subscription initial event gets NetworkTimeout
(13-04-2017 07:57 AM)simonc Wrote:  Yes, this should be fine. Internally, I'd expect the control point stack thread that sends the unsubscribe request to block until the device stack completes or fails its initial event. Externally, client code won't notice any problem - the public unsubscribe API will still complete immediately.

Actually, the immediate return to the application would be a problem if this also happens for the subsequent resubscribe.

This is because I am starting the application's InitialEvent timeout from the time when the resubscribe call returns to the application, based on the assumption that the server is sending its initial subscription message for the new subscription at about this time.

If this happens when the server is still stuck in a blocked attempt to send the initial subscription message from the previous aborted subscription, this timing will be wrong and the InitialEvent timeout for the new subscription might complete too soon.
Find all posts by this user
Quote this message in a reply
22-05-2017, 09:35 PM (This post was last modified: 22-05-2017 09:36 PM by simoncn.)
Post: #7
RE: Subscription initial event gets NetworkTimeout
I have discovered that there is a problem with the subscribe and unsubscribe APIs returning before the internal threads have completed their processing.

If the application calls unsubscribe() immediately followed by subscribe(), the internal threads can execute out of order so that the server receives the unsubscribe request after the subscribe request. This means the client state is out of sync with the server state and if the client application does a subsequent unsubscribe(), this hangs indefinitely.

As a temporary workaround, I have added a 4-second delay between the application's unsubscribe() and subscribe() calls but this is not a good solution. Could there be some mechanism for ohNet to notify the application when an unsubscribe or subscribe operation is fully complete?
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump: