proxmox-mirrors/mirror_frr
1
0
Fork 0
mirror of https://git.proxmox.com/git/mirror_frr synced 2025-08-13 21:01:47 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

bgpd: write NOTIFY non-blockingly

Browse Source 
switching the socket to blocking may well block the entire bgpd process
for some time if our peer is overloaded (which may well be the original
reason for the NOTIFY)

The error handling is slightly different from the previous ML discussion
on this;  buffer exhaustion isn't technically a fatal TCP error, and we
should probably proceed with FSM actions according to a sent NOTIFY
(adjusting timers) even if we didn't manage to get the NOTIFY onto the
wire.

Acked-by: Leonid Rosenboim <lrosenbo@wrs.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This commit is contained in:
David Lamparter 2013-07-31 14:39:41 +02:00
parent 9e47abd862
commit 8ff202e2d3
1 changed files with 5 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
bgpd/bgp_packet.c
View File

@ -719,14 +719,15 @@ bgp_write_notify (struct peer *peer)
return 0;
assert (stream_get_endp (s) >= BGP_HEADER_SIZE);
/* Put socket in blocking mode. */
val = fcntl (peer->fd, F_GETFL, 0);
fcntl (peer->fd, F_SETFL, val & ~O_NONBLOCK);
/* Stop collecting data within the socket */
sockopt_cork (peer->fd, 0);
/* socket is in nonblocking mode, if we can't deliver the NOTIFY, well,
* we only care about getting a clean shutdown at this point. */
ret = write (peer->fd, STREAM_DATA (s), stream_get_endp (s));
/* only connection reset/close gets counted as TCP_fatal_error, failure
* to write the entire NOTIFY doesn't get different FSM treatment */
if (ret <= 0)
{
BGP_EVENT_ADD (peer, TCP_fatal_error);