Back to the main page.
Bug 135 - allowuser not updated
| Status | CLOSED FIXED |
| Reported | 2010-08-28 15:42:00 +0200 |
| Modified | 2011-01-05 12:01:11 +0100 |
| Product: | FieldTrip |
| Component: | peer |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Linux |
| Importance: | P1 major |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Marcel Zwiers - 2010-08-28 15:42:35 +0200
peer('allowuser',{...}) is not updated properly (and probably also allowgroup etc). To reproduce this problem startup 2 slaves, one with peerslave('allowuser', {yourusername}) and one without restrictions. Now do the following: >>clear all >>peerinfo This gives you 2 peers (assumaning there are no other peers in the network) >>peermaster('allowuser','yourusername') >>peerinfo This gives the same nr as peers as before >>clear all >>peermaster('allowuser','yourusername') Only now you get the desired nr of peers (namely 1).
Marcel Zwiers - 2010-08-28 20:09:35 +0200
Of course, the peerslave without restrictions should run under a different username (e.g. public)
Robert Oostenveld - 2010-08-30 09:23:54 +0200
The situation was that the update would take 5 seconds. The allowXXX is implemented in the discover thread, and only when a previous discovery expired (i.e. after 5 seconds), the new discovery of the same host would be processed and filtered according to the allowXXX rules. I have changed the code of the mex file: after updating the allowXXX rules, the peerlist is erased and all hosts have to be re-discovered. Consequently, all announced peers will be compared with the allowXXX rules. See SVN revision 1568 on http://code.google.com/p/fieldtrip/source/detail?r=1568
Robert Oostenveld - 2011-01-05 11:57:06 +0100
selected a long list of resolved bugs from roboos and changed the status into "RESOLVED"