Event notifications: Sockets are not closed when the subscription is disabled
Opened this issue · 2 comments
clispec
notify("Получить нотификации из backend"), cli_notify("transactions_stream", "1", "xml");
no("Команда отмены") notify("Отключить нотификации из backend"), cli_notify("transactions_stream", "0", "xml");
run systemctl restart clixon-backend.service
$ netstat -an | grep clixon
unix 2 [ ACC ] STREAM LISTENING 13470 /var/run/clixon/clixon-pc.sock
run cli command show configuration candidate cli
$ netstat -an | grep clixon
unix 2 [ ACC ] STREAM LISTENING 13470 /var/run/clixon/clixon-pc.sock
unix 3 [ ] STREAM CONNECTED 13536 /var/run/clixon/clixon-pc.sock
then I do it a few more times show configuration candidate cli
$ netstat -an | grep clixon
unix 2 [ ACC ] STREAM LISTENING 13470 /var/run/clixon/clixon-pc.sock
unix 3 [ ] STREAM CONNECTED 13536 /var/run/clixon/clixon-pc.sock
everything all right
now I'm subscribing to withdrawals notify
the subscription is running well
$ netstat -an | grep clixon
unix 2 [ ACC ] STREAM LISTENING 13470 /var/run/clixon/clixon-pc.sock
unix 3 [ ] STREAM CONNECTED 13536 /var/run/clixon/clixon-pc.sock
unix 3 [ ] STREAM CONNECTED 15380 /var/run/clixon/clixon-pc.sock
now I unsubscribe no notify
when unsubscribing, the rpc is not sent that I unsubscribed, but when subscribing it is sent, is this how it should be?
$ netstat -an | grep clixon
unix 2 [ ACC ] STREAM LISTENING 13470 /var/run/clixon/clixon-pc.sock
unix 3 [ ] STREAM CONNECTED 13536 /var/run/clixon/clixon-pc.sock
unix 3 [ ] STREAM CONNECTED 15380 /var/run/clixon/clixon-pc.sock
and the socket does not close
now I'm subscribing to withdrawals notify
the subscription is running well
$ netstat -an | grep clixon
unix 3 [ ] STREAM CONNECTED 15383 /var/run/clixon/clixon-pc.sock
unix 2 [ ACC ] STREAM LISTENING 13470 /var/run/clixon/clixon-pc.sock
unix 3 [ ] STREAM CONNECTED 13536 /var/run/clixon/clixon-pc.sock
unix 3 [ ] STREAM CONNECTED 15380 /var/run/clixon/clixon-pc.sock
and sockets are created this way but not closed, is that how it should be?
Yes.
If a client process creates a subscription a new session is created.
When the process is exited, the session is closed.
However, if a client process creates a subscription, closes it, and the makes a new subscription, the old session is still up.
According to RFC 1588 the client should issue a NETCONF close_session for the subscription session, but does not.
The primary thing that needs implemented is a session-id negotiating mechanism.
This is done in NETCONF via the hello protocol, but RFC5277 does not mention a way to do this.
One may need to look at RFC 8639/8640 as well.