Date: Tue, 23 Nov 2004 18:24:48 +0200 From: Martin Eugen <martin.eugen@gmail.com> To: Jo?o Carlos Mendes Lu?s <jonny@jonny.eng.br>, freebsd-net@freebsd.org, freebsd-hackers@freebsd.org, Joerg Sonnenberger <joerg@britannica.bec.de> Subject: Re: resolving routes externally Message-ID: <966ba91e04112308246616d1b8@mail.gmail.com> In-Reply-To: <20041123135236.GC1032@britannica.bec.de> References: <966ba91e04112301052fed8d6b@mail.gmail.com> <41A33E4F.8060705@jonny.eng.br> <20041123135236.GC1032@britannica.bec.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 23 Nov 2004 14:52:36 +0100, Joerg Sonnenberger <joerg@britannica.bec.de> wrote: > On Tue, Nov 23, 2004 at 11:42:39AM -0200, Jo?o Carlos Mendes Lu?s wrote: > > >So I started to look at the ARP > > >code, but it of course lacks the kernel - userland communication > > >interface. I would appreciate any ideas about what would be the easier > > >way to implement such a thing where the kernel could wait (up to some > > >reasonable time-out) a userland daemon to install a new route. > > > > Why don't you simply discard the packet and wait for the next retry? > Because the network is not like the internet, packet error correction and so on is done at lower layers, I mean... if there are some packets that are equivalent to the TCP SYNs, the 'SYN' timeout in our case is in minutes (because it is believed the host or a link is down or something else that could take longer time to resolve). This is bad, because connections will be established within some minutes... > Or alternatively use an internal queue of limited size to keep track of > those packages. This is probably the only solution I can think of right now, but I think poking a queue at regular, short intervals seems to me quite expensive, isn't it? Or perhaps there could be a netgraph node that handles the queue and connects to the userland daemon... but this could make things much more complicated... ? > > Joerg >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?966ba91e04112308246616d1b8>