SEO
vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
02-18-2008, 07:17 AM
| ||||
| ||||
 Re: Anatomy of a bug On Sun, Sep 12, 2004 at 01:07:34PM -0700, Erblichs wrote: > Henning Bauer and others, > > Sorry, if I see code that is forking an object > and then two owners point to that newly alloc'ed > object, I have a reference count that is > incremented, so when the ref count is decremented > to 0, the struct could be dealloc'ed. > > If the peer was flapping, I would have expected > a temporary delay for deletion of the struct, > but then again I would have to think whether > the peer count would have been temporarlly > decremented and re-incremented. > > If some type of copy-on-write (COW)is then > performed (after the fork), then a struct is > alloc'ed. Yes, I ASSUMED that for each peer_cnt > that a new struct is alloc'ed and then init'ed. > > Since I assumed and know BGP is per AS (Autonomous > System), I assumed that a AS peer count would be > incremented with each fork and with a alloc'ed > stuct. The total number of peers would be thus the > sum of all the AS peer counts. And again a global > value with peer_cnt would be questionable. I was > not questioning the need for the value.. > > > bullshit. of course we need the count to size the pfd and idx2peer > > array. > > Since I have not read the code, I am not going to > comment on this item immediately above.. > > So, Bottom line I would a always expect that based on > a hello from a unknown proto-peer, I would create a > peer with the interface that the peer was seen on, > its source IP address, whether it was manually or > dynamiclly created, the AS it resides in, UNLESS the > interface was passive. The peer count would be > incmented in the AS and the peer would be associated > with other peers in this AS. Its state would by some > indication of 1-way and that we need to perform some > type of capability negotiation. > > Forgive me, I am just a little pigheaded and haven't > looked at your minimal implimentation that impliments > some features of bgp. I have ONLY done a commerical > implimentation of BGP. Thus, I don't know if it is > wise to review and suggest particular write-or-rewite > sections of this code.. > Please read the code and don't assume something. As you should know peers are configured and not created on initial hello. The peers list changes on reload (yes we do atomic config reloads) and in the case of templates. In both cases the count and the poll and idx2peer arrays need to be adjusted. That's it. Forgive me, I am just a opensource programmer and haven't looked at your we-have-all-buttons-and-switches closed-source implementation of a server that implements all [the stupid] RFCs and drafts about bgp. I have ONLY done a FREE implemntation of BGP. Thus, I don't know if it is wise to reply to some guy that thinks to know how to rewrite code without ever looking at it. -- :wq Claudio      |
Linear Mode
