Re: [netconf] Current activities on RESTCONF/NETCONF to support paging

[Qin Wu <[e-mail]>]

-----邮件原件-----
发件人: netconf [mailto:[e-mail]] 代表 tom petch
发送时间: 2019年3月15日 1:07
收件人: Wisotzky, Sven (Nokia - DE/Stuttgart) <[e-mail]>; Juergen Schoenwaelder <[e-mail]>
抄送: [e-mail]
主题: Re: [netconf] Current activities on RESTCONF/NETCONF to support paging

----- Original Message -----
From: "Wisotzky, Sven (Nokia - DE/Stuttgart)" <[e-mail]>
Sent: Thursday, March 14, 2019 12:14 PM

> Depends on whatever we call here a crash. The challenging part of
NETCONF/RESTCONF is, that the client would not know how big the get/get-config reply would become. Having a JS-based WebUI client running a RESTCONF query, you easily end up in situations, where you basically need to terminate the javascript because it runs out of memory. And I've even seen situations, where the browser itself did not respond anymore (swapping to disk, ...).

One afternoon, I set an SNMP get-next going on RMON and it was still going the next day; I then tried over a weekend and it was still going the next week.  Data was being added to the table faster than my high speed LAN could retrieve it.  Neither system crashed although response times for other applications elongated.

I am reminded of e-mail where a POP client may access a very large list of e-mails on a server.  The first response is a count of how many there are currently; the client can then request the summary data for each before deciding which to download in full.  This was designed before the cloud was thought of and it is a system that still works well.

[Qin]:Have a little bit brainstorm, in HTTP Streaming, we may create manifest file for the location of additional streams or next chunk. The encoder or automated scripts upload the files to NETCONF/RESTCONF server, the client need to download such manifest file.

Tom Petch







>
> By introducing a protection mechanisms like max-count, the client can
control to a certain extent how much data will be received. And by using paging for post loading in the background, the client could still decide if it is possible to load another page or not. So when running out-of-memory or when start swapping, the client could avoid loading any further pages. Generally I am thinking this is a very reasonable aka controlled  approach.
>
> With NETCONF today, for sure one could terminate the NETCONF sessions
if too much data is received and might try using a XML stream reader to process what has been received so far. But would claim that this is not a good approach at all and should be avoided.
>
> /wiso
>
>
>
>
> On 14.03.19, 11:49, "Juergen Schoenwaelder"
<[e-mail]> wrote:
>
>     On Thu, Mar 14, 2019 at 10:07:33AM +0000, Wisotzky, Sven (Nokia -
DE/Stuttgart) wrote:
>     >
>     > However, as per my initial post below, just defining a limit
(aka max-count) is a very efficient initial step to improve loading time and avoid crashes.
>
>     Sorry, but if code crashes, then someone has to fix the code.
Adding
>     query parameters is not the right answer for this.
>
>     /js
>
>     --
>     Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>     Phone: [phone]         Campus Ring 1 | 28759 Bremen |
Germany
>     Fax:   [phone]
<https://www.jacobs-university.de/>
>
>
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>

_______________________________________________
netconf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netconf