On Tue, 14 Nov 2006 10:39:16 -0800
Rao Shoaib <[EMAIL PROTECTED]> wrote:
[...]
> > in.ndpd/main.c:
> > 1547: *ick* I'm not a big fan of a library support routine logging'ng
> > an error. Sure, its an unlikely error.
> We are following the convention. BTW why do you see an issue with this ?
I'm not sure what convention you are referring to. If its just using
poll_add() as it exists I don't like how its implemented but I don't
see an issue of ya'all using it.
> > Also poll_add() could be
> > simplified by doing the check for -1 and fd in the same loop
> Can you please elaborate.
There is a loop which checks to see if the fd matches. And then there
is a loop to find the first free spot. The could be combined. When
I wrote this that made a lot of sense. Not so sure now that I think
aobut it more.
> > and
> > realizing that after the realloc you know where the next free slot is.
> > It would be nice to fix while you are there...
> >
> Sure we can fix this. The only issue is testing. If we start cleaning up
> in.ndpd we may introduce new behavior and we don't have much time left
> for testing. Will it be ok if we filed bugs and fixed these issues
> separately.
These are not really bugs. They are general code maintenance issues. I
realize they are at or beyond the boundary of your code. I think its
worthwhile to fix things like this as you run across them. I doubt there
is real economic support for the overhead of filing bugs to do the same.
Its up to you at this point. Do as you wish.
> > 1710-1714: Why not just keep track of these in
> > phyint_create()/phyint_delete()?
> >
> Great idea, will do ;-).
> > 1716,1754,1779, 1793 You send this chunk of related information out in
> > 4 pieces ignoring errors. What happens if one of them fails? How does
> > the receiver interpret the data? Imagine the sequence: request,
> > reponse, response, response, drop, rerequest, drop, drop, drop,
> > response. Is it old data? It is related?
> >
> Good Point. We did think about this and put the burden of verifying the
> integrity of the data on the receiver.
By received I assume you mean requester.
>
> Based on the first packet the receiver will know how many and what type
> of packets it needs to receive. If a packet[s] gets dropped the client
> will have to flush the socket (perhaps close/open) and re issue the
> request. If the first packet gets dropped, based on the type, the
> client will know that it did not get the first packet and needs to
> close/open/reissue. We could check for error conditions on the send but
> there is no way for us to retrieve the packets that have already been
> sent. Or we could send all the information out as one large packet, We
> did not take this route as it limits how big the packet can be. If you
> think our approach is not good enough we are open for suggestions.
Given the intention to use a local transport its not a big deal. OTOH
it seems to me that a request identifier of some type would allow a fair
bit of flexibility in the future.
>
> > tables.h
> >
> > defs.h
> >
> > in.routed/input.c
> >
> > in.routed/rdisc.c:
> > This is just a style change. This just makes diff'ng against any
> > changes outside of SMI all that much more difficult. Although for this
> > sourcebase I don't think that is common.
> >
> >
> Even though you are OK with our our changes. Can you elaborate as I
> don't understand your comment about the style change.
Misread on my part. Missed the removal of static on drs (eventhough I saw
the extern elsewhere). Sorry.
mph
>
> Thanks,
>
> Rao.
>
_______________________________________________
networking-discuss mailing list
[email protected]
