Re: keepalives (fwd)

[Gilad Arnold]

Sorry for the self-reply, I have some doubts about my previous post... 
(somehow I had in mind that paging is zebra/vtysh is done explicitly, 
that is using explicit terminal height values, vty callbacks, etc; it 
seems that the only place it's done is that 'show ip bgp' routine)


Gilad Arnold wrote:

> Okay, I took a look again, it seems that it's a bit different from what 
> we last discussed: this guy says he was using vtysh to control his bgpd; 
> in this case, if you take a look at bgpd/bgp_route.c/bgp_show(), you'll 
> see that there's no paging in case vty->type == VTY_SHELL_SERV (which I 
> believe to be the case with vtysh, isn't it?). In this case, bgpd keeps 
> dumping it's output lines into the vtysh fd, that is keep executing the 
> output call chain, eg: bgpd/bgp_route.c/route_vty_out(), then 
> lib/vty.c/vty_out(), note that for the vtysh case (vty_shell_serv()) it 
> just uses write() calls into vty->fd! So, guess what, the unix socket is 
> filled out pretty soon, and the write() call simply blocks!! Now, that's 
> real process blocking, and is definitely a major flaw in bgpd design wrt 
> vtysh interface.

Apparently, vtysh is using a real pipe when paging output, so my 
explanation about socket overflow and process blocking needs further 
justification: is it possible for the write() call to block? Hopefully, 
I wasn't *that* wrong, at least by claiming that bgpd should not block 
when accessed from normal vty (non-shell-server).

Any ideas?... ;->

Gilad