From ashkan170 at gmail.com Sun Aug 23 08:32:12 2009 From: ashkan170 at gmail.com (Ashkan Zamani) Date: Sun, 23 Aug 2009 20:02:12 +0430 Subject: [Diffusion-users] Seems to be a bug in OneWayMatch function Message-ID: <53d867d90908230832r2a059281l8629a5577a9c9169@mail.gmail.com> Hello, I'm doing my research on directed diffusion using ns 2.27. My application is two-phase pull and I have changed the publish data in the manner that they no more match any of the interests of sink nodes. The result is that in the OneWayMatch() function of attrs.cc, the second "for" never ends and is never broken by any of the cases in "switch". In the code, it is assumed that the two attribute vectors do not match only when they have at least one uncommon keys because there is just one point in the function that returns with false value and it occures when the find_matching_key_from() function fails to find the corresponding key. The surprising point is that when the two keys match, why the corresponding values are not checked if they don't satisfy the interest and the function is returned with false value? Regards, Mahdi Zamani AmirKabir University of Technology From johnh at ISI.EDU Sun Aug 23 20:36:00 2009 From: johnh at ISI.EDU (John Heidemann) Date: Sun, 23 Aug 2009 20:36:00 -0700 Subject: [Diffusion-users] Seems to be a bug in OneWayMatch function In-Reply-To: <53d867d90908230832r2a059281l8629a5577a9c9169@mail.gmail.com> Message-ID: <19582.1251084960@dash.isi.edu> On Sun, 23 Aug 2009 20:02:12 +0430, Ashkan Zamani wrote: >Hello, > >I'm doing my research on directed diffusion using ns 2.27. My application is >two-phase pull and I have changed the publish data in the manner that they >no more match any of the interests of sink nodes. The result is that in the >OneWayMatch() function of attrs.cc, the second "for" never ends and is never >broken by any of the cases in "switch". In the code, it is assumed that the >two attribute vectors do not match only when they have at least one uncommon >keys because there is just one point in the function that returns with false >value and it occures when the find_matching_key_from() function fails to >find the corresponding key. The surprising point is that when the two keys >match, why the corresponding values are not checked if they don't satisfy >the interest and the function is returned with false value? > >Regards, >Mahdi Zamani >AmirKabir University of Technology Can you send your specific publish and subscribe attribute vectors? You may well have found a bug, but without the inputs, it's hard to tell. -John Heidemann From ashkan170 at gmail.com Mon Aug 24 10:10:07 2009 From: ashkan170 at gmail.com (Ashkan Zamani) Date: Mon, 24 Aug 2009 21:40:07 +0430 Subject: [Diffusion-users] Seems to be a bug in OneWayMatch function In-Reply-To: <19582.1251084960@dash.isi.edu> References: <53d867d90908230832r2a059281l8629a5577a9c9169@mail.gmail.com> <19582.1251084960@dash.isi.edu> Message-ID: <53d867d90908241010m268ec9asb03e9934b722e377@mail.gmail.com> Hello, I didn't change the attribute vector of publish nodes and it is just the same that is released in 2.27 (In 2pp_ping_sender.cc, method setupPublication()): attrs.push_back(NRClassAttr.make(NRAttribute::IS, NRAttribute::DATA_CLASS)); attrs.push_back(NRAlgorithmAttr.make(NRAttribute::IS, NRAttribute::TWO_PHASE_PULL_ALGORITHM)); attrs.push_back(LatitudeAttr.make(NRAttribute::IS, 60.00)); attrs.push_back(LongitudeAttr.make(NRAttribute::IS, 54.00)); attrs.push_back(TargetAttr.make(NRAttribute::IS, "F117A")); I changed the vector of subscribe nodes just in one attribute, the LongitudeAttr (In 2pp_ping_receiver.cc, method setupSubscription()): attrs.push_back(NRClassAttr.make(NRAttribute::IS, NRAttribute::INTEREST_CLASS)); attrs.push_back(NRAlgorithmAttr.make(NRAttribute::IS, NRAttribute::TWO_PHASE_PULL_ALGORITHM)); attrs.push_back(LatitudeAttr.make(NRAttribute::GT, 54.78)); attrs.push_back(LongitudeAttr.make(NRAttribute::LE, 50)); attrs.push_back(TargetAttr.make(NRAttribute::IS, "F117A")); I changed the attribute in the way that never matches the corresponding attribute of publish nodes but as I already said, the internal "for" of OneWayMatch() loops endlessly. Regards, Mahdi Zamani AmirKabir University of Technology On Mon, Aug 24, 2009 at 8:06 AM, John Heidemann wrote: > On Sun, 23 Aug 2009 20:02:12 +0430, Ashkan Zamani wrote: > >Hello, > > > >I'm doing my research on directed diffusion using ns 2.27. My application > is > >two-phase pull and I have changed the publish data in the manner that they > >no more match any of the interests of sink nodes. The result is that in > the > >OneWayMatch() function of attrs.cc, the second "for" never ends and is > never > >broken by any of the cases in "switch". In the code, it is assumed that > the > >two attribute vectors do not match only when they have at least one > uncommon > >keys because there is just one point in the function that returns with > false > >value and it occures when the find_matching_key_from() function fails to > >find the corresponding key. The surprising point is that when the two keys > >match, why the corresponding values are not checked if they don't satisfy > >the interest and the function is returned with false value? > > > >Regards, > >Mahdi Zamani > >AmirKabir University of Technology > > Can you send your specific publish and subscribe attribute vectors? > You may well have found a bug, but without the inputs, it's hard to tell. > > -John Heidemann > From ashkan170 at gmail.com Tue Aug 25 01:25:26 2009 From: ashkan170 at gmail.com (Ashkan Zamani) Date: Tue, 25 Aug 2009 12:55:26 +0430 Subject: [Diffusion-users] Seems to be a bug in OneWayMatch function In-Reply-To: <53d867d90908241010m268ec9asb03e9934b722e377@mail.gmail.com> References: <53d867d90908230832r2a059281l8629a5577a9c9169@mail.gmail.com> <19582.1251084960@dash.isi.edu> <53d867d90908241010m268ec9asb03e9934b722e377@mail.gmail.com> Message-ID: <53d867d90908250125r5a476351v5a841a3e92ed830f@mail.gmail.com> Hello, That was a mistake of mine in tracing the code. I have confused the failure of my eclipse debugger with a bug that causes to run out of boundary of the attr_vec2. By the way, to whom followed this thread, the end of the attribute vector is checked in find_matching_key_from() and if the itr2 reaches the end, the function returns with NULL and the invoker (the OneWayMatch()) also returns with false. Sorry for the mistake and thank you for your response. Mahdi Zamani AmirKabir University of Technology On Mon, Aug 24, 2009 at 9:40 PM, Ashkan Zamani wrote: > Hello, > > I didn't change the attribute vector of publish nodes and it is just the > same that is released in 2.27 (In 2pp_ping_sender.cc, method > setupPublication()): > > attrs.push_back(NRClassAttr.make(NRAttribute::IS, > NRAttribute::DATA_CLASS)); > attrs.push_back(NRAlgorithmAttr.make(NRAttribute::IS, > NRAttribute::TWO_PHASE_PULL_ALGORITHM)); > attrs.push_back(LatitudeAttr.make(NRAttribute::IS, 60.00)); > attrs.push_back(LongitudeAttr.make(NRAttribute::IS, 54.00)); > attrs.push_back(TargetAttr.make(NRAttribute::IS, "F117A")); > > I changed the vector of subscribe nodes just in one attribute, the > LongitudeAttr (In 2pp_ping_receiver.cc, method setupSubscription()): > > attrs.push_back(NRClassAttr.make(NRAttribute::IS, > NRAttribute::INTEREST_CLASS)); > attrs.push_back(NRAlgorithmAttr.make(NRAttribute::IS, > NRAttribute::TWO_PHASE_PULL_ALGORITHM)); > attrs.push_back(LatitudeAttr.make(NRAttribute::GT, 54.78)); > attrs.push_back(LongitudeAttr.make(NRAttribute::LE, 50)); > attrs.push_back(TargetAttr.make(NRAttribute::IS, "F117A")); > > I changed the attribute in the way that never matches > the corresponding attribute of publish nodes but as I already said, the > internal "for" of OneWayMatch() loops endlessly. > > Regards, > Mahdi Zamani > AmirKabir University of Technology > > > > On Mon, Aug 24, 2009 at 8:06 AM, John Heidemann wrote: > >> On Sun, 23 Aug 2009 20:02:12 +0430, Ashkan Zamani wrote: >> >Hello, >> > >> >I'm doing my research on directed diffusion using ns 2.27. My application >> is >> >two-phase pull and I have changed the publish data in the manner that >> they >> >no more match any of the interests of sink nodes. The result is that in >> the >> >OneWayMatch() function of attrs.cc, the second "for" never ends and is >> never >> >broken by any of the cases in "switch". In the code, it is assumed that >> the >> >two attribute vectors do not match only when they have at least one >> uncommon >> >keys because there is just one point in the function that returns with >> false >> >value and it occures when the find_matching_key_from() function fails to >> >find the corresponding key. The surprising point is that when the two >> keys >> >match, why the corresponding values are not checked if they don't satisfy >> >the interest and the function is returned with false value? >> > >> >Regards, >> >Mahdi Zamani >> >AmirKabir University of Technology >> >> Can you send your specific publish and subscribe attribute vectors? >> You may well have found a bug, but without the inputs, it's hard to tell. >> >> -John Heidemann >> > > From ashkan170 at gmail.com Thu Aug 27 03:37:03 2009 From: ashkan170 at gmail.com (Ashkan Zamani) Date: Thu, 27 Aug 2009 15:07:03 +0430 Subject: [Diffusion-users] How to trace diffusion events? Message-ID: <53d867d90908270337y28a579d4od074ba5894e132c@mail.gmail.com> Hello, I'm looking for a way to generate trace lines about various diffusion events through CMUTrace. Since CMUTrace is based on packet tracing and diffusion rely on messages instead and diffusion never redirects the same packets it receives, it would be hard to generate some types of traces such as drop of data messages. For example, consider the DiffusionRouting object has received a message that its attribute vector does not match any of the subscribed interests of sub_list therefore it will drop the message instantly. The question is that what is the best way for DiffusionRouting object to generate a trace line notifying that the incoming message was dropped. Currently, I notify the DiffAppAgent object by returning a boolean value in recv() method of DiffusionRouting and then the DiffAppAgent sends down a dummy packet with a special field in its common header (hdr_cmn) indicating message drop. Although this solves the problem but it's actually a messy trick. Is there any reasonable way? Mahdi Zamani, AmirKabir University of Technology Biocomputings Lab.