Re: real time neighbour table updates
On Sun, 13 Mar 2011 10:02:18 +0200 Timo wrote: TT As you can see on the tracker I've had a look at this patch. I stopped TT however because I'm not convinced that the introduction of the new flag TT NETSNMP_CACHE_AUTO_SYNCHRONIZED is justified. TT TT I added some more explanation now why it's there. I'll have time to fix TT things on the patch today/tomorrow. Hopefully we get it in merging state TT soon. I think the concept you are talking about for the cache is ok, but I'm not sure that auto-sychronized is the right name. It's more of a keep-alive, isn't it? simply bumping the expiration time when the cache is used? My question with regards to this patch is whether or not it is actually doing synchronization. That is, are stale entries being removed? For true synchronization, I'd expect that if the cache expires and is released, and then reloaded immediately (before any changes to the kernel data), it would contain exactly the same data. Also, I see lots of code added and deleted. I just want to make sure that the table will still work on systems without netlink. - robert -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: real time neighbour table updates
On Wed, 16 Mar 2011 17:25:51 +0200 Timo wrote: TT I think the concept you are talking about for the cache is ok, but I'm not TT sure that auto-sychronized is the right name. It's more of a keep-alive, isn't TT it? simply bumping the expiration time when the cache is used? TT TT Correct. The flag name is misleading. I first thought that it'd do more TT things, but all it had to do is bump the timestamp on each GET. So if TT you have a good new name, I can run sed and post a new patch. How about NETSNMP_CACHE_RESET_TIMER_ON_USE? Please add a note in the documentation that using this flag without a method of keeping the cache fresh will result in stale data if polling is more frequent than the expiration timer. TT Correct. The kernel sends deletion events, which in turn are sent as arp TT entry updates containing NETSNMP_ACCESS_ARP_ENTRY_FLAG_DELETE. So it is TT fully synchronized. TT [...] TT As you see, it's now split to arp_common, arp_netlink and arp_linux. The TT arp_linux side basically keeps the old behaviour. Great. That alleviates my concerns. Thanks. Robert -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: real time neighbour table updates
On 03/16/2011 07:49 PM, Robert Story wrote: On Wed, 16 Mar 2011 17:25:51 +0200 Timo wrote: TT I think the concept you are talking about for the cache is ok, but I'm not TT sure that auto-sychronized is the right name. It's more of a keep-alive, isn't TT it? simply bumping the expiration time when the cache is used? TT TT Correct. The flag name is misleading. I first thought that it'd do more TT things, but all it had to do is bump the timestamp on each GET. So if TT you have a good new name, I can run sed and post a new patch. How about NETSNMP_CACHE_RESET_TIMER_ON_USE? Please add a note in the documentation that using this flag without a method of keeping the cache fresh will result in stale data if polling is more frequent than the expiration timer. Sure. New patch uploaded. - Timo -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: real time neighbour table updates
On 03/11/2011 07:24 PM, Bart Van Assche wrote: 2011/3/4 Wes Hardaker harda...@users.sourceforge.net mailto:harda...@users.sourceforge.net On Tue, 01 Mar 2011 07:54:10 +0200, Timo Teräs timo.te...@iki.fi mailto:timo.te...@iki.fi said: TT What's the usual time frame for getting patches reviewed and committed? TT Could someone take a look at this? It's actually on my todo list to go review the patches. They're always reviewed before the next release, and I (and others) try to do them frequently but it depends on our real work life as to when we get to them. The important thing is that because they're in the tracker we can't forget about them, so you put it in the right place! [and I got better for a bit about reviewing more regularly, but you hit me during a particularly busy time; I should have time next week to review] As you can see on the tracker I've had a look at this patch. I stopped however because I'm not convinced that the introduction of the new flag NETSNMP_CACHE_AUTO_SYNCHRONIZED is justified. I added some more explanation now why it's there. I'll have time to fix things on the patch today/tomorrow. Hopefully we get it in merging state soon. Thanks for the reviewing and feedback so far! - Timo -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: real time neighbour table updates
2011/3/4 Wes Hardaker harda...@users.sourceforge.net On Tue, 01 Mar 2011 07:54:10 +0200, Timo Teräs timo.te...@iki.fi said: TT What's the usual time frame for getting patches reviewed and committed? TT Could someone take a look at this? It's actually on my todo list to go review the patches. They're always reviewed before the next release, and I (and others) try to do them frequently but it depends on our real work life as to when we get to them. The important thing is that because they're in the tracker we can't forget about them, so you put it in the right place! [and I got better for a bit about reviewing more regularly, but you hit me during a particularly busy time; I should have time next week to review] As you can see on the tracker I've had a look at this patch. I stopped however because I'm not convinced that the introduction of the new flag NETSNMP_CACHE_AUTO_SYNCHRONIZED is justified. See also http://sourceforge.net/tracker/?func=detailaid=3123596group_id=12694atid=312694 . Bart. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
Re: real time neighbour table updates
On Tue, 01 Mar 2011 07:54:10 +0200, Timo Teräs timo.te...@iki.fi said: TT What's the usual time frame for getting patches reviewed and committed? TT Could someone take a look at this? It's actually on my todo list to go review the patches. They're always reviewed before the next release, and I (and others) try to do them frequently but it depends on our real work life as to when we get to them. The important thing is that because they're in the tracker we can't forget about them, so you put it in the right place! [and I got better for a bit about reviewing more regularly, but you hit me during a particularly busy time; I should have time next week to review] -- Wes Hardaker Please mail all replies to net-snmp-coders@lists.sourceforge.net -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
