Re: RE: Bug fixed! (RSVP/ns)

[K Sun <ksun@essex.ac.uk>]

Hello,
     Thank you for your message. Prevoiusly, I sent an email to you ask 
a quesitona bout RSVP/ns. Did you receive it?


> I'm sorry for not having too much time anymore for giving any kind
> of support for RSVP/ns. However, I do have a comment on that "bug"
> and the proposed change:
> 
> > -(918)              sender->get-addr());
> > +(918)		    r->sender->get_addr());
> 
> Did you make sure that it is correct instead of just changing it
> because it looked good and didn't cause any error anymore? I don't
> know the code well enough anymore to really make any comment
> about that without having a close look, so I am just asking.

    As for this point, I can not there is no errors caused by such 
change. Definitely, before I 100% understand all your source code, how 
can I gurantee anything? I beg your pardon. 
    However, I can give you the reason that I make such a correction.
In "RSVPAgent::process_resv_message(RSVPmessage *msg, nsaddr_t 
fromhop)" (the file "rsvp.cc"), first, you get the FILTER_SPEC object 
within Resv message with (line 886) "sender = (FILTER_SPEC 
*)msg->get_first(10);", but it just means "sender" stores the address 
of such an object, instead of a copy of this object.
    However, you use (line 904) "msg->delete_first(10);" deleting this 
object. From your file "rsvp-messages.cc", we can find, acutally, you 
release the memory unites of this object. So, when you call 
(line 918) "sender->get_addr()", I do not know what "sender" points to. 
Perhaps, in some OS, although you have released the memory units, it 
still keep the contents of those units. If so, your program runs OK. 
However, if the OS will not keep the contents of those memory units 
anymore after you release, there will be an error. However, before your 
(line 904) "msg->delete_first(10);", you have done (line 891) "r = 
new_rsb(s, p, sender->get_addr(), fl, "FF", nhop->get_hop(), 
tv->get_r(), fromhop);" . So, in your new rsb, the information of 
sender->con->addr has been stored. Therefore, we should use the 
information you have stored. So, use "r->sender->get_addr()" instead of 
"sender->get_addr()".
     Actually, in your (line 916) " tcl.evalf("%s upcall-resv %d %f %d 
%d", name(),  s->sid,    r->fspec->get_rate(), r->fspec->get_size(), 
sender->get_addr());", you also use the value you stored in the new 
rsb, like "r->fspec->get_rate".... except the address of "sender".
     I feel, according to my understanding of your idea. Perhaps, you 
have a slip here when you wrote your code, although you original idea is
still right. 
     

> I still have my doubts about running RSVP/ns in ns-2.1b5 anyway,
> and while I could never make any guarantees about the correctness
> of the code in 2.1b3, the guarantees when running it in 2.1b5 are
> even lower.

   Oh, you are too modest! :-).. In my opinion, your programming skill 
is very good, at least better than me. I can read it (just probably), 
but if I creat them by myself, it should be very very difficult for me.

 
> Am I missing something? There are two problems with your statement
> above:
> 1) You CAN send a Resv message automatically when receiving a Path
> message. You simply have to redefine the Path-Upcall for that. I
> am pretty sure it was done in one of the examples provided with the
> RSVP/ns package.
> 2) Even if you would not be able to do it automatically, I wouldn't
> see the huge problem. You make it sound as if that would be a bug, 
> but in fact there is nothing in the RSVP-related RFCs that says
> that a reservation should be set up automatically upon reception
> of a path message. The fact that you CAN do it in RSVP/ns is just
> an additional feature.

   Thanks you for your answers. This is just I want to know. Thanks 
again! 
    I think, in the near future, I may ask more questions about it 
although I have thought any more questions at this moment. Hope your 
patient help.

   Keep in touch,

    Best Wishes,
           Sun Kai

> 
> Best Regards,
> Marc
> 
> PS: To everyone who requested the RSVP/ns code from me: I will get
> to it this weekend, I promise. ;)
> 
> -- 
> Marc Greis                                           greis@cs.uni-bonn.de