Michael,
Thanks a lot for your comments. My comments are in line.
Michael Hunter wrote:
On Mon, 30 Oct 2006 12:08:13 -0800
Anders Persson <[EMAIL PROTECTED]> wrote:
Hi Everyone,
The Networking MIBs project, which adds support for the latest
TCP/UDP/IP MIBs, is now open for code review.
You can find the webrev at:
http://cr.grommit.com/~apersson/mib_gate_webrev/
or, if you are within SWAN you can find it at:
file:///net/nptbld.sfbay/disk1/mib_gate/webrev
Please send in your comments to [EMAIL PROTECTED], or
directly to me by 11/13/06.
netstat.c:
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 ?
Also poll_add() could be
simplified by doing the check for -1 and fd in the same loop
Can you please elaborate.
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.
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.
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.
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.
Thanks,
Rao.
_______________________________________________
networking-discuss mailing list
[email protected]
