Hello,
I'm having trouble with the tests about the search functionality. They assume that the routing table is filled when the search message are sent but in my case the tests don't let enough time (in particular the ones with large topologies like TestGossiper_Search_Query_Keywords_Complex). Could we use the DataRequest/Reply and SearchRequest/Reply messages to update the routing table or is it up to the search functionality to handle the case where no route exist ?
Thanks!
Hi,
The search requests should be broadcast (meaning sent to the network neighbors). So, at least for the requests, you do not actually need the routing table.
The topology and the supplied budget in TestGossiper_Search_Query_Keywords_Complex ensure that all the nodes receive the request.
Kirill
Thanks, but my problem is that when the Gossiper receives the search request and wants to respond, the route to the search's origin does not exist yet as the routing rumors did not have time to propagate.
What should the Gossiper do then ? Or is it a problem with the way I handle rumor messages ?
Does your gossiper send a route rumor at start-up? This was the requirement from the previous homework. If you have it implemented, it seems to me like all the nodes should have the necessary routes by the time they need to reply. Or it does not work even with this?
Kirill
They do but in the test, the peer node addresses are added to the list after the gossiper have started so the first route rumor message does not get sent to anyone. However, the next route messages do due to the route timer. It just seems that the routing table does not have enough time to build itself before the search request come in.
If the route to the request's origin is not known, my current solution throws an error which makes the test fail, maybe it would be best to just drop the request ? By adding more delay before sending the search request, the test succeeds.
I guess it comes down to my implementation of route rumor messages but I have talked to my teammate and he has the same problem.
My solution was to just print a warning that no neighbours are available to advertise your routes to and wait until the routes are added. My reasoning is that the HW1 handout doesn't explicitly specify how route rumors should behave in case there are no neighbours and if you check the model binaries for this HW they also do not throw an error if their route rumors have no one to advertise to.
Thank you for the info ! But I found a bug in my code that solved the issue of slow route propagation altogether.
Cheers!
Update: I found a pretty tricky bug in my code, I will fix it and try again. I'll come back to you if that does not solve my issue.
Follow the pulses of EPFL on social networks
© 2023 EPFL, all rights reserved