Re: [ns] More addressing questions

[Sean Murphy <murphys@Teltec.DCU.IE>]

> > Initially, I thought that this might be attributed to use of integers to
> > represent node addrs rather than unsigned integers. I'm not so sure that
> > this is the case now, but in any case, I found that the addr field in the
> > ns_addr_t struct is a *signed* int. Is there any reason for this, or can
> > I change it to an unsigned int without breaking things? (I think it might
> > affect some multicasting stuff, but I'm not sure).
> >
> 
> nam should be independent of how ns works internally (i.e.  the only thing
> matters to nam is the nam
> trace file ) . I just browsed trace.cc , and it seems to me currently nam
> uses integer to assign node id .

Yes. But that's not what I was getting at. My question was more focussed
on the fact that nsaddr_t is an int32_t rather than a uint32_t and if I
want to have full flexibility to be able to specify the IP address of a
node using usual (IPv4) dotted quad notation then it makes sense to me
that the address field should be a uint rather than an int. Of course, if
this causes loads of other things to break, then it's probably not worth
it, but if not it seems much more natural to me.

Incidentally, while looking at this stuff, I came across a limitation in
the hash function in sfq.cc - if the node addresses are sufficiently
large, the hash function can return a negative value. Since the return
value of this function is used to index an array, this can have unsavoury
consequences. If node addrs just equal node ids (ie small numbers), then
this situation will probably never arise, but if node addrs are decoupled
from node ids, then this could become a problem.

Sean.

-----
Sean Murphy,			Email: sean.murphy@teltec.dcu.ie
Teltec Ireland,			Phone: +353-1-7045080
DCU, Dublin 9,			Fax:   +353-1-7045092
Ireland.