The sequence number is unknown to the server. StatusBadSequenceNumberUnknown (0x807A0000)

[cngobd]

When I subscribe tags, it returns an error: The sequence number is unknown to the server. StatusBadSequenceNumberUnknown (0x807A0000)
What the means of this error?

[magiconair]

This could be related to #189

[magiconair]

Could you run this with the OPC_DEBUG=debug environment variable set and show the debug output?

[magiconair]

@769139671 could you check if #271 solves your problem?

[cngobd]

@magiconair thank you for your help!

[magiconair]

Does the patch fix the problem?

[cngobd]

not yet,
I use the WireShark to capture the date after a tag value changed, I find that my IGS Server sometimes send more than one hundred bytes but sometimes only send about fifty bytes.
gopcua subscription works well when got more than one hundred bytes , if it got about fifty bytes, it will cause: ->The operation timed out. StatusBadTimeout (0x800A0000) -> The sequence number is unknown to the server. StatusBadSequenceNumberUnknown (0x807A0000) -> what's this publish result?

[magiconair]

This has a smell. Maybe you are getting the wrong error message. Can you capture the the traffic with Wireshark and post it? If you want to send it privately please find me on https://keybase.io/

[cngobd]

the data captured when the subscription work well :

0000   00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00   
0010   00 9d 61 b8 40 00 40 06 00 00 a9 fe bc 59 a9 fe   
0020   bc 59 c0 9e db 34 b8 fa 39 31 ba 46 a6 bd 50 18   
0030   08 03 ac b9 00 00 0b 02 00 00 0b 00 00 00 01 00   
0040   3d 03 b7 b3 cc fe fc 6c d5 01 0c 00 00 00 00 00   
0050   00 00 00 00 00 00 00 00 00 00 09 00 00 00 01 00  
0060   00 00 05 00 00 00 00 05 00 00 00 b7 b3 cc fe fc   
0070   6c d5 01 01 00 00 00 01 00 2b 03 01 1f 00 00 00  
0080   01 00 00 00 e9 03 00 00 0d 01 00 35 32 91 fe fc   
0090   6c d5 01 35 32 91 fe fc 6c d5 01 00 00 00 00 01  
00a0   00 00 00 00 00 00 00 00 00 00 00 

the data captured when cause error :

0000   00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00   
0010   00 2c 61 b6 40 00 40 06 00 00 a9 fe bc 59 a9 fe   
0020   bc 59 c0 9e db 34 b8 fa 39 2d ba 46 a6 bd 50 18   
0030   08 03 eb 15 00 00 01 00 00 00                    

how to use debug? I add "opc.Debug()" in my main.go but it did not print anything

[jkissinger]

I'm getting this as well, this is with debug logging on and OPC_DEBUG=debug:

debug: conn 1: recv MSGF with 52 bytes
debug: uasc 1/6: recv MSGF with 52 bytes
debug: uasc 1/6: res:The operation timed out. StatusBadTimeout (0x800A0000)
debug: uasc 1/6: err: The operation timed out. StatusBadTimeout (0x800A0000)
debug: sending *ua.ServiceFault to handler
debug: uasc 1/7: send *ua.PublishRequest with 74 bytes
debug: conn 1: recv MSGF with 141 bytes
debug: uasc 1/7: recv MSGF with 141 bytes
debug: uasc 1/7: res: OK (0x0)
debug: uasc 1/7: recv *ua.PublishResponse
debug: sending *ua.PublishResponse to handler
2019/09/19 10:23:10.587686 The sequence number is unknown to the server. StatusBadSequenceNumberUnknown (0x807A0000)
debug: uasc 1/8: send *ua.PublishRequest with 74 bytes
debug: conn 1: recv MSGF with 141 bytes
debug: uasc 1/8: recv MSGF with 141 bytes
debug: uasc 1/8: res: OK (0x0)
debug: uasc 1/8: recv *ua.PublishResponse
debug: sending *ua.PublishResponse to handler

This only happens with the first (99% of the time) or second notification of a subscription in my testing. I've tested up to 1000 sequential notifications.

@magiconair testing with #271 made no difference.

[dwhutchison]

I tried reproducing this and wasn't able to on my dev server. What server are you running against?
I noticed you had a timeout right before the error. What are your timeouts and subscription settings at?

If it's happening right at the start, that makes sense that #271 wouldn't help; that should only help for really long-running sessions.

[cngobd]

@dwhutchison I am using IGS Server (Industrial GateWay OPC Server)

[cngobd]

@magiconair @dwhutchison I updated my IGS Simulation Server, this is a kind of kepwear simulator, and for free. I am looking forward that you can test it.
https://sjtueducn-my.sharepoint.com/:u:/g/personal/liukun_sjtu_edu_cn/Ea3cj8S7-fhPgQuURNXC_-cBSRC8ms5Ak7qtyxZkqNj7zw?e=HSoQQ6
thank you very much!

[dwhutchison]

I've tested with IGS and a few other servers and I'm still unable to reproduce it.
Can you provide more information on how to reproduce it?

Please provide:

• Operating system
• Client configuration code (with sensitive information removed)
• Wireshark logs of the error with SecurityMode = None

[cngobd]

@dwhutchison
Operation system: Windows 10 Professional
Client configuration code:

endpoints, err := opcua.GetEndpoints("opc.tcp://localhost:49310")
	if err != nil {
		log.Fatal(err)
	}
	opts := []opcua.Option{
		opcua.SecurityPolicy("None"),
		opcua.SecurityModeString("None"),
		opcua.SecurityFromEndpoint(ep, ua.UserTokenTypeAnonymous),
	}

Wireshark logs of the error:
https://github.com/769139671/IGS_Server/blob/master/opcua.pcapng

[dwhutchison]

Thanks. The wireshark log helped tons.

Your publish requests were timing out before the publish response came in. The timeout on the requests was set to 10s but your messages were coming in ~15s later.

Can you check with #280 and see if that fixes the issue?

[cngobd]

@dwhutchison Thank you for your help, how to change the timeout longer? I want to make subscription work continuously and persistent

[cngobd]

@dwhutchison It is unreasonable that the timeout was set to 10s. If the value in my IGS Server changed slowly, the gopcua subscription will not receive the message.

[dwhutchison]

I realize I didn't explain the fix very well, but you're right. 10s is the default timeout for typical Requests that the server responds to immediately (ReadRequest, BrowseRequest, etc.). PublishRequests are different in that the server intentionally holds off responding to them until there's data to report. The stack is aware of this and sets a higher timeout value for PublishRequests based on the subscription parameters. For example, using the settings in the subscribe example, the PublishRequest timeout becomes 25min.
After looking into this issue, I found a bug which is causing all requests (including PublishRequests) to just use the default timeout of 10s, which should be fixed in #280.

Can you please confirm that #280 resolves your problem?

[cngobd]

@dwhutchison Thank you! It have resolved the previous problem: The sequence number is unknown to the server.
And how to use the setting in the subscription example now? How to make the PublishRequest timeout become 25min?

[dwhutchison]

You can adjust it by setting the appropriate parameters in the SubscriptionParameters argument to client.Subscribe. The parameters that affect it are Interval and MaxKeepAliveCount and the math is simply timeout = Interval * MaxKeepAliveCount (in ms). The defaults are:

DefaultSubscriptionMaxKeepAliveCount          = 3000
DefaultSubscriptionInterval                   = 100 * time.Millisecond

which turns into a 5-minute timeout. The subscribe example sets an Interval of 500ms, making this 25min.

Regardless, you shouldn't need to worry too much about this. The server knows about these as well and will respond with an empty keepalive response if no data is available within this time period.