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

----- Original Message -----
From: "Wisotzky, Sven (Nokia - DE/Stuttgart)" <sven.wisotzky@nokia.com>
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.

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"
<j.schoenwaelder@jacobs-university.de> 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: +49 421 200 3587         Campus Ring 1 | 28759 Bremen |
Germany
>     Fax:   +49 421 200 3103
<https://www.jacobs-university.de/>
>
>
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>