Client-server architecture

[Vivek Singh]

HI Serj,

Just wanted to know if there is a way to stop forking of a new child klishd server for every new klish client. I want to have N:1 design where N clients connects with same server.

In current architecture, since i am using klish-plugin-sysrepo to connect with the sysrepo, it makes the backend heavier as every forked klish server will have to have the schema files. we have a huge set of schema files which is making the server heavier.
Also for each client when it connects , it has to go and read the schema file from sysrepo which is time consuming and in my case taking around 9-10 seconds.

Previously even for a tab command from inside the client, it was forking a new server to get the autocompletion, i was able to stop this by updating the klishd.conf 

<klish>
    <server>
        <fork-mode>reuse</fork-mode>
        <max-clients>10</max-clients> <!-- Limit concurrent clients -->
    </server>
    <logging>
        <path>/var/log/klishd.log</path>
        <level>debug</level>
    </logging>
</klish>

Can you please point out if there is any xml tag which i can use so that the client does not fork child server everytime. Or any code change which we can do to achieve this.

Regards,
Vivek Kumar Singh

[Serj Kalichev]

Hi

I suppose you mean klish 3 version...

There is no way to don't fork listening klishd for each client. You need to rewrite klishd. Probably it's not so easy. But you don't need to rewrite libklish library. It actually contains the most klish code.

But note you misunderstand the architecture. One of the goal of version 3 was to don't re-parse any config for each client. Klish 3 parses XML config files only once while klishd service start. All forked processes have config already parsed and don't spend any time for this.

The sysrepo has unusual (in my opinion) architecture. It has shared memory region to store data. When some program uses sysrepo or libyang library it just gets access to shared memory with pre-created data structures. The locking is used for consistence. When program executes sr_connect() to "connect" to sysrepo the library doesn't parse YANG schema. Actually sr_connect() is slow operation but there is no right way to make it faster. The sysrepo documentation says to don't fork process with connected sysrepo. Theoretically it can brake sysrepo mechanisms. Each process must have its own connection. The first sysrepo-plugin version used one connection for all forked processes. It worked well in practice. But sysrepo can be changed. So I use sysrepo developer's recommendations. So only long delay while fork is sr_connect().

About autocompletion and type checking... The "sym" (symbol, function to execute on ACTION) can be sync or async. By default it async for the security reasons. Async symbols will be forked. But for standard types I made some sync "syms" to don't fork on autocompletion and type checks. Note the scripts can't be executed without forking at all. Additionally klishd event loop is async and it's not good to sleep within sync "sym". You can create your own plugin with C-written sync symbols.

--
You received this message because you are subscribed to the Google Groups "klish" group.
To unsubscribe from this group and stop receiving emails from it, send an email to klish+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/klish/CAEDQv8eprcTwu0L8kRi_KZ%3Dsv%2BankBcpSyP2JM_2BYUdXGF0ZA%40mail.gmail.com.

[Vivek Singh]

HI Serj,

Thanks Alot for the clarification.

Your insights were really helpful.

There are few other clarifications is needed :
1) Memory usage: With each server forked, i could see an increase in memory of around 100 mb. you mentioned that forked process does not parse the schema files but do they store the schema files ?
2) Can we support pagination with klish 3.0. basically i have modified he klish 3.0 to support the show command. There are some outputs which is huge and we do want to support pagination for the same. Is it possible to support it.
3) I read that pipe command is currently not supported with klish 3.0. Is there a way to support the same. Can we expect the same in future releases or can you provide some guidance on how to achieve the same?
4) Session management: We need to support session management. How can we achieve the same with klish providing the session details.

5) Autonomous notifications: Is it possible to support autonomous notifications in klish. I mean if a daemon wants to post a notification then can that be displayed on the cli prompt directly. In this process, daemon will be posting the notification and same needs to display directly on the cli prompt. this will be a one way communication from daemon to klish cli. 

6) As you have mentioned, sr_connect() takes time for each forked klishd server. the time taken is around 4-5 seconds in core-i7-64  and it nmore for lower processor. is there a way to reduce this timing. because everytime if a client is started, it takes the same time for getting the schema for autocompletion for the first time.

Please provide your inputs on these

It will really be helpful for us.

Regards,
Vivek Kumar Singh

Your inputs and insights will 

To view this discussion visit https://groups.google.com/d/msgid/klish/70d160be-3999-4e39-aef9-a88fa4c60c7a%40gmail.com.

[Serj Kalichev]

Hi

1. The forked process contains already parsed (while daemon execution) copy of klish XML configs. The named shared memory contains parsed YANG schema. The klish has nothing with shared memory. Klish just use this memory via libsysrepo and libyang calls. When you speak about memory usage you probably means virtual memory. When process forks the new process is created with copy of parent process data. So new process uses the same amount of memory as a parent process does. Note it's a "virtual" memory. Linux uses CoW mechanism while forking. It means that parent and child actually use the same physical memory pages after fork(). Memory page will be really copied if child changes the content of page. The memory usage calculation by the summing processes virtual memory usage is wrong. Probably it will be better to analyze the amount of free memory of system or something like this.

2. The pagination is internal feature of klish-3. The klish utility (client) has the config file /etc/klish/klish.conf with settings. See the klish.conf file within klish source tree. It contains setting which pager to use and pager enable/disable flag. The example file contains comments.

3. Pipe command (i.e. FILTER) is already implemented. The document is partly out of date. Now I have not enough time to update and translate the documentation. But I will... sometime...

4. What do you exactly mean?

5. The async notifications are partly implemented. The KTP protocol (protocol beetween klish client and klishd daemon) has NOTIFICATION message. It's async. But problem is how to generate notification from the daemon to client? What is the source and condition of notification? I have no idea. Probably something like <SHED> tag can be implemented to be executed periodically. But now it's not planned. How do you plan to use the notifications?

6. The 4-5 seconds is too much. I have not such huge delay. It's slow but not 4-5 seconds. It's strange. Try to write test program (not using klish) that just connects to sysrepo and measure the delay. We had problem with slow execution of large number of set/del commands. So the solution is connect just once and then execute all the command within this session. The klish-plugin-sysrepo repository contains srp_load utility that can do that. It's usefull for some kind of automatization.

To view this discussion visit https://groups.google.com/d/msgid/klish/CAEDQv8exPzTysg-VJKbnSJDA4N0gYEj4pZGqumcWjjOyimGG3A%40mail.gmail.com.

[Serj Kalichev]

Hello!

The klish and klish-plugin-sysrepo projects now have English documentation. The documentation is translated by AI engine so it contains some artifacts and inaccuracy.  Unfortunately the pictures text are not translated yet. But even such documentation is better than nothing.

https://src.libcode.org/pkun/klish/src/master/docs/klish3.en.md

https://src.libcode.org/pkun/klish-plugin-sysrepo/src/master/docs/klish-plugin-sysrepo.en.md