protopeer-general — General mailing list for ProtoPeer

Re: [ProtoPeer-general] Small changes in NeighborManager

[Wojciech G. <wg...@in...>]

Hey Frank,

Thanks for the update.

BTW, I noticed that often people don't use the neighbor manager directly 
but instead keep the neighbors locally in their application peerlet 
together with the per-neighbor application state. That's actually a more 
convenient solution than using the NeighborManager which is oblivious to 
the per-neighbor application state and that has to be kept elsewhere. 
Applications also send their own application-specific disconnect 
messages or even handle Peer.stop() in different ways. So does that make 
neighbor manager of limited use?

Well, no. NeighborManager is good for signaling and requesting the 
neighbor set changes which many other peerlets rely on, so we need it.
I guess a good solution would to turn the NeighborManager into an 
interface such that if some peerlet maintains a set of neighbors it 
could implement the NeighborManager.

Just a thought. What do you think?

Cheers,
W.

> Dear Wojtek,
> 
> I just committed two small changes regarding the notification of the 
> neighbors of a peer when Peer.stop() is called.
> 
> The first change was to remove the following code from Peer.java
> 
>         // FIXME: Why is it here and not in the NeighborManager?
>         if (getNeighborManager() != null) {
>             for (Finger neighbor : getNeighborManager().getNeighbors()) {
>                 sendMessage(neighbor.getNetworkAddress(), new 
> DisconnectNotification());
>             }
>         }
> 
> This code was also in NeighborManager.java. Therefore, it should not 
> make a big difference.
> 
> The second change was in NeighborManager.java. I added a switch to turn 
> on/off the notification of the neighbors when NeighborManager.stop() is 
> called. The default behavior is that neighbors are notified using a 
> DisconnectMessage (the same behavior as before). However, now this 
> behavior can be disabled by NeighborManager.setNotifyNeighborsOnStop(false).
> 
> As the neighbor management is quite a central component, I wanted to 
> inform you about the changes.
> 
> Regards,
> Frank
> 



Tysiace zabawnych wierszyków.Dodaj swoj
Sprawdz >>> http://link.interia.pl/f1fcd

[ProtoPeer-general] Small changes in NeighborManager

[Frank L. <leh...@in...>]

Dear Wojtek,

I just committed two small changes regarding the notification of the 
neighbors of a peer when Peer.stop() is called.

The first change was to remove the following code from Peer.java

        // FIXME: Why is it here and not in the NeighborManager?
        if (getNeighborManager() != null) {
            for (Finger neighbor : getNeighborManager().getNeighbors()) {
                sendMessage(neighbor.getNetworkAddress(), new 
DisconnectNotification());
            }
        }

This code was also in NeighborManager.java. Therefore, it should not 
make a big difference.

The second change was in NeighborManager.java. I added a switch to turn 
on/off the notification of the neighbors when NeighborManager.stop() is 
called. The default behavior is that neighbors are notified using a 
DisconnectMessage (the same behavior as before). However, now this 
behavior can be disabled by NeighborManager.setNotifyNeighborsOnStop(false).

As the neighbor management is quite a central component, I wanted to 
inform you about the changes.

Regards,
Frank

-- 
Dipl.-Inform. Frank Lehrieder
University of Wuerzburg,
Institute of Computer Science,
Department of Distributed Systems (Informatik III),
Am Hubland, 97074 Wuerzburg, Germany

Tel: +49 931 31-86651
Fax: +49 931 888-6632
leh...@in...
http://www3.informatik.uni-wuerzburg.de/staff/lehrieder/

[ProtoPeer-general] flow-based model working great

[Wojciech G. <woj...@ep...>]

Hi Frank,

I just started using the flow-based model. I transitioned a sizable 
application from the UniformDelayModel to the flow-based model without 
too many problems.

There is just one thing: if I try to allocate many addresses in a model 
configured with the UplinkBottleneckTopology that doesn't have enough 
links defined (less than the number of addresses I'm allocating) I get a:
> java.lang.NullPointerException
> 	at protopeer.network.flowbased.Connection.startTransmission(Connection.java:110)
> 	at protopeer.network.flowbased.FlowBasedNetworkModel.startTransmission(FlowBasedNetworkModel.java:190)
> 	at protopeer.network.flowbased.FlowBasedNetworkModel.establishConnection(FlowBasedNetworkModel.java:158)
> 	at protopeer.network.flowbased.FlowBasedNetworkInterface.sendMessage(FlowBasedNetworkInterface.java:85)
> 	at protopeer.Peer.sendMessage(Peer.java:335)
It would be good to throw a NetworkException or a NetworkModelException 
with a meaningful message so that people know that it's a config problem 
and not a bug.

How are the addresses actually mapped to the topo links? In the order 
the links were added to the topo?

Thanks,
Wojtek

[ProtoPeer-general] no more MessageAttachments

[Wojciech G. <wg...@in...>]

Hi,

I just got rid of one legacy unused feature: the MessageAttachments. 
(rev 67) Cloning and serialization should be a bit faster now.

Cheers,
Wojtek

Re: [ProtoPeer-general] Random Numbers in Protopeer

[Frank L. <leh...@in...>]

Hi Wojtek,

thank you for your hints. I think I solved the problem now.

I iterated over the keyset of a HashMap. I knew that the order of the 
elements in the map may change during one run of the program, but I did 
not know that running the same programm twice may result in different 
orders of the entries in the HashMap. The reason is, that the 
implementation of the hashCode() method takes into account some kind of 
memory address of the object 
(http://www.javaworld.com/community/?q=node/1006). As a consequence, the 
same object may have different hashCodes during different runs of the 
same program.

Now, I'm using objects of type LinkedHashMap. The order of the elements 
returned by an iterator is guaranteed to be the insertion order of the 
elements.

I've already commited the changes to the sourceforge repository.

Frank


Wojciech Galuba schrieb:
> Hi Frank,
>
> Repeatability is tricky to achieve. Look in your code for the following:
>
> - calls to Math.random()
> - references to java.util.Random or 
> cern.jet.random.engine.RandomEngine or any other random number 
> generators that you might be using
> - calls to Collections.shuffle()
> - calls to System.nanoTime() or System.currentTimeMillis()
>
> If you find anything try to replace it with calls from the 
> protopeer.util.RandomnessSource
>
> Also make sure that all your compareTo implementations guarantee the 
> total order.
>
> have patience and determinism shall be yours ;)
> Wojtek
>
>> Hello Wojtek,
>>
>> just a short question:
>>
>> I fixed the master_seed in RandomnessSource.java to a certain value. 
>> Consequently, two subsequent runs of a simulation should provide 
>> exactly the same result. However, that's not the case. Do you have 
>> any idea, where other potential source of randomness are? Perhaps I 
>> missed to initialize another seed?
>>
>> Regards,
>> Frank
>>

-- 
Dipl.-Inform. Frank Lehrieder
University of Wuerzburg,
Institute of Computer Science,
Department of Distributed Systems (Informatik III),
Am Hubland, 97074 Wuerzburg, Germany

Tel: +49 931 31-86651
Fax: +49 931 888-6632
leh...@in...
http://www3.informatik.uni-wuerzburg.de/staff/lehrieder/

Re: [ProtoPeer-general] Random Numbers in Protopeer

[Wojciech G. <woj...@ep...>]

Hi Frank,

Repeatability is tricky to achieve. Look in your code for the following:

- calls to Math.random()
- references to java.util.Random or cern.jet.random.engine.RandomEngine 
or any other random number generators that you might be using
- calls to Collections.shuffle()
- calls to System.nanoTime() or System.currentTimeMillis()

If you find anything try to replace it with calls from the 
protopeer.util.RandomnessSource

Also make sure that all your compareTo implementations guarantee the 
total order.

have patience and determinism shall be yours ;)
Wojtek

> Hello Wojtek,
> 
> just a short question:
> 
> I fixed the master_seed in RandomnessSource.java to a certain value. 
> Consequently, two subsequent runs of a simulation should provide exactly 
> the same result. However, that's not the case. Do you have any idea, 
> where other potential source of randomness are? Perhaps I missed to 
> initialize another seed?
> 
> Regards,
> Frank
> 

Re: [ProtoPeer-general] devel v0.9

[Wojciech G. <wg...@in...>]

Hey,

OK, the Experiment.createNetworkModel() method was renamed to 
createDelayLossNetworkModel() (to differentiate from what Frank is 
working on). By default createDelayLossNetworkModel()
returns a UniformDelayModel(0,0), i.e. no-delay model. You've probably 
overriden the old createNetworkModel() to return something else, you 
need to rename it to createDelayLossNetworkModel() and things should get 
back to normal.

One trick to avoid these type of problems in the future is to tag your 
overriden methods with @Override so when something gets refactored 
you'll get a compile error.
http://stackoverflow.com/questions/94361/when-do-you-use-javas-override-annotation-and-why

The Experiment class spec is a bit shaky, it's difficult to come up with 
  initialization code that could be reused across all the apps... so 
Experiment is likely to change... unless you guys have some ideas on how 
to clean this up :)

Cheers,
Wojtek

> Hi ProtoPeer-Hackers,
> 
> I'm right now testing v0.9 of ProtoPeer, I just took my 0.8 application
> and changed from 0.8 to 0.9.
> 
> A strange effect is, that now all(!) my messages, that normally are
> distributed over the time of simulation, are now happening on simulation
> time 0.0.
> I'm using the UniformDelayModel, but it doesn't put any delay, I guess.
> 
> Do I have to change something in my application?
> 
> 
> Thanks a lot!
> Maximilian
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> ProtoPeer-general mailing list
> Pro...@li...
> https://lists.sourceforge.net/lists/listinfo/protopeer-general
> 
> 


----------------------------------------------------------------------
Wygrywaj nagrody na Lepiuchy.pl!
Sprawdz >>> http://link.interia.pl/f1f57

[ProtoPeer-general] devel v0.9

[Michel, M. <mi...@do...>]

Hi ProtoPeer-Hackers,

I'm right now testing v0.9 of ProtoPeer, I just took my 0.8 application
and changed from 0.8 to 0.9.

A strange effect is, that now all(!) my messages, that normally are
distributed over the time of simulation, are now happening on simulation
time 0.0.
I'm using the UniformDelayModel, but it doesn't put any delay, I guess.

Do I have to change something in my application?


Thanks a lot!
Maximilian

[ProtoPeer-general] new features to assist in debugging

[Wojciech G. <woj...@ep...>]

Hi,

Just checked in some new features into 0.9.

1. The currently used Experiment is accessible via 
Experiment.getSingleton(). This starts returning non-null only after one 
of the two Experiment.init*Run() methods are called.

2. Experiment.getCurrentlyExecutingPeer() returns the peer whose 
networking or timer event is currently executing, null otherwise.
Use it only for debug this might be turned off for performance, do not 
rely on that in the "production" code.

3. Rich logging

Add this to your log4j.properties:

log4j.appender.mylogger.layout=protopeer.util.VerbosePatternLayout
log4j.appender.mylogger.layout.ConversionPattern=%p - %F:%L - %C{1}.%M - 
%m%n

Where "mylogger" is your logger.

This will result in the logging lines like this:

2566118.618973822 - pidx=140, paddr=326, pid=0.7419944828530498, 		 
pstate=RUNNING - WARN - NetMapperNetworkModel.java:177 - 		 
NetMapperNetworkModel.getLinkQuality - quality unknown...

First number is the simulation time, then the peer index number, peer 
address, peer identifier and peer state, and the usual: log level, 
filename, line number, class name, method name and the logged message.

That rich logging helps a lot with debugging and saves you from dumping 
peer IDs and peer addresses in your log messages.

I tested all of the above in sim, but should work in live as well.

Cheers,
Wojtek

[ProtoPeer-general] Experiment getting singletonized

[Wojciech G. <wg...@in...>]

Hi,

I'm turning the Experiment class into the singleton pattern. If anyone 
is doing that at the moment, let me know, so we don't conflict. I'll try 
not to break too much of the initialization code.

Cheers,
Wojtek

----------------------------------------------------------------------
Dodaj strone www do katalogu. Pokaz ze istniejesz!
Sprawdz jak >> http://link.interia.pl/f1f2a 

[ProtoPeer-general] attachments useful? can we axe them?

[Wojciech G. <wg...@in...>]

Hi,

Is anyone using the MessageAttachment feature?
I looked at my apps and I think we could remove it. That would simplify 
and speed up things (cloning and serialization esp.).

If there are no objections I'll remove it in 0.9.

Cheers,
Wojtek

----------------------------------------------------------------------
Zapytaj o Milosc, Prace, Zdrowie, Rodzine ...
Sprawdz >> http://link.interia.pl/f1f27 

[ProtoPeer-general] offtopic: application speedup

[Michel, M. <mi...@do...>]

Hi,

I have a little bit offtopic question: what would be a good way to speed
up self-written protocols for ProtoPeer, which java-profilers are
recommendable?


Best regards,
  Maximilian

[ProtoPeer-general] ProtoPeer blog launched

[Wojciech G. <wg...@in...>]

Hi All,

We've just launched the ProtoPeer blog, a place for the ProtoPeer news, 
announcements, idea & feature discussion and hopefully other things. 
Let’s see how it works out.

Cheers,
Wojtek

----------------------------------------------------------------------
Dzwon taniej na zagraniczne komorki!
Sprawdz >>  http://link.interia.pl/f1f0e 

[ProtoPeer-general] the blog

[Wojciech G. <wg...@in...>]

Ah... yes here is the link to the blog :)

http://protopeer.epfl.ch/blog/

Wojtek

----------------------------------------------------------------------
>> Sprawdz swoja najblizsza przyszlosc!
>> http://link.interia.pl/f1f0b   

[ProtoPeer-general] We are demoing at P2P2008

[Wojciech G. <woj...@ep...>]

Come and check out the ProtoPeer demo at the P2P2008 conference!
http://www.p2p08.org/program

Cheers,
Wojtek

[ProtoPeer-general] ProtoPeer v0.8 is out!

[Wojciech G. <woj...@ep...>]

Dear All,

ProtoPeer v0.8 is out, you can download it at:
http://protopeer.epfl.ch/download.html
(you may need to reload the page in your browser if you've visited it 
before)

The documentation (including the tutorial) is at the Wiki:
http://protopeer.epfl.ch/wiki

 From now on all announcements and discussion will be happening at this 
mailing list:
pro...@li...

You can subscribe to the list here:
https://lists.sourceforge.net/lists/listinfo/protopeer-general

Have fun prototyping,
Wojtek

[ProtoPeer-general] test from interia

[Wojciech G. <wg...@in...>]

test

----------------------------------------------------------------------
Kobietkom tez zdarzaja sie wtopy.
Zobacz filmik >>> http://link.interia.pl/f1e63

[ProtoPeer-general] test

[Wojciech G. <wg...@in...>]

test2

----------------------------------------------------------------------
Wyjezdzasz? Sprawdz, co mozesz ciekawego obejrzec!
Przewodniki >>> http://link.interia.pl/f1e5f

[Protopeer-general] test

[Wojciech G. <woj...@ep...>]

First email test