libnetconf2
libnetconf2 copied to clipboard
CESNET
Notification and Edit-Config in parallel
Hi,
What I am trying to do is application can send notification at any time while the client also can send edit-config anytime. If the application is bombarding with notification, so my nc_recv_reply will keep processing notification in while loop. Will I get my edit-config response in between? If yes, how?
One more question I have, If client send edit-config and goes to nc_recv_reply to RPC response. But in nc_recv_reply I can see the timeout is 20 sec, so if in between I keep getting the notification. My timeout will be reset after every notification processing? So if notification is bombarded from Application will I ever get RPC reply or will I ever come out of the while loop?
Hi, as for the first question, you should get the messages in the order they come so there may be some notifications first (which you can detect based on the return value) that you can ignore until you actually receive the reply.
As for the second question, the timeout is measured until a message of any kind arrives, which is then returned as return value (and for reply even the content). Like I said before, it is ordered, so if the reply was sent, you should get it sooner or later. But you are right that if it was not sent and notifications would keep coming in, you would never get the timeout. But we are talking about the CLI here, which is definitely not perfect, so I do not think it is really a problem.
Regards, Michal
Hi @michalvasko ,
Yeah I know it is a CLI and it is not a problem. Actually I am writing my own Client application. Just wanted to ask if we can avoid this kind of scenario by reducing the timeout everytime a msg is processed which is not edit config reply. But how would I know how much time it waited before getting any REPLY?
Is there any reason the REPLY timeout is kept as 20 sec. Can I reduce it to 5 sec or something. Will it create any other problem?
Hi, when implementing it on your own, you can easily learn how much time was spent and just measure it. Also, I think it originally was 5 seconds but it was not long enough for some requests so I increased it, that is all, no special reason.
Regards, Michal
Hi,
Yeah I can do that. I was thinking if any API is exposed in libnetconf for that or in some reply structure it is available. Anyways I will do this timer based thing.
One last question I have, Can you tell me what kind of request made you increase the timeout? Like get-config of lot of attribute in a tree or something? Because when server has lost connection due to some reason and client has not detected it, so it will be stuck waiting for 20 sec before it accepts the new call home connection. 20 sec is a long duration.
Because I want to reduce it to 5sec
Hi,
the timeout is mostly a problem on the slower embedded architectures but get may take a long time even on the standard ones when you have a lot of operational subscriptions, for example.
Also, handling RPCs/notifications and accepting new sessions should be independent in netopeer2 and not block each other.
Regards, Michal
Hi,
Yeah. Call home and RPC/Notification handling are in separate thread. But if Server detects that connection is lost but client didnt then server will start sending new call home request. But client already has a active session for that server. So it is important that it should not get stuck in RPC calls or waiting for reply for very long time. My requirement is I can have only one connection with one server at a time. So the current session should be terminated and then new call home should be accepted.