Created attachment 3060 [details]
uan-examples

The patch file contains some stuff from the patch in bug #2413, and it doesn't apply smoothly.

Could you please re-upload it ?

Thanks.

Created attachment 3066 [details]
uan-examples

Created attachment 3069 [details]
uan-examples.patch

fix coding style

Comments:

The actual patch contains two additions: two new applications, and 3 examples. The new applications are used in the examples.
I'd split the two, but this can be done while committing.
Nevertheless, I'd use two separate patches.

About the content:
- Applications:

1) Don't use Buffers where it's not needed. I.e.,
UdpApplication::Send (Address dst, const Buffer dataBuffer)
but the other app is similar.

I'd pass a Ptr<Packet> to the app, it's far less cumbersome. The caller can safely build the packet with whatever it wants.

Mind, this is a personal opinion, others might disagree.

2) You set the port in the Application, but if one would like to mimic BSD sockets, you should actually pass both the destination AND the port 

3) Are these application really necessary ?
Looking at the code, one could safely skip them and do the same directly in the examples.

- Examples:
1) Don't use global variables:
NodeContainer nodeContainer;
Pass it to the functions requiring it.

2) Don't split the code in micro-functions, they make the code *less* readable. Just put everything in the main and divide the sections with a comment line.
Just leave the functions that need to be called through Schedule, these are necessary.


Thanks for the effort !

(In reply to Tommaso Pecorella from comment #5)
> Comments:
> 
> The actual patch contains two additions: two new applications, and 3
> examples. The new applications are used in the examples.
> I'd split the two, but this can be done while committing.
> Nevertheless, I'd use two separate patches.

I agree (however, not sure about these specific applications)

> 
> About the content:
> - Applications:
> 
> 1) Don't use Buffers where it's not needed. I.e.,
> UdpApplication::Send (Address dst, const Buffer dataBuffer)
> but the other app is similar.
> 
> I'd pass a Ptr<Packet> to the app, it's far less cumbersome. The caller can
> safely build the packet with whatever it wants.

I agree

> 
> Mind, this is a personal opinion, others might disagree.
> 
> 2) You set the port in the Application, but if one would like to mimic BSD
> sockets, you should actually pass both the destination AND the port 
> 
> 3) Are these application really necessary ?
> Looking at the code, one could safely skip them and do the same directly in
> the examples.

Before agreeing to adding more applications, I'd like to explore whether existing applications could be extended.  I would like to avoid a lot of similar, simple applications because I think it will be confusing to users (we already have udp-client, udp-trace-client, udp-echo-client, and onoff-application, which are not that different).

> 
> - Examples:
> 1) Don't use global variables:
> NodeContainer nodeContainer;
> Pass it to the functions requiring it.
> 
> 2) Don't split the code in micro-functions, they make the code *less*
> readable. Just put everything in the main and divide the sections with a
> comment line.
> Just leave the functions that need to be called through Schedule, these are
> necessary.

I don't mind the proposed structure; there are other examples of such in our codebase.

Created attachment 3075 [details]
uan-examples.patch

Bug 2889 - to address the applications patch
I changed the applications send/receive APIs to use Ptr<packet> instead of Buffer.

For the code structure, let me know whatever you agree on.

I tried rewriting the examples without using applications, and the first problem I ran into is that the sockets need to stay alive during the simulation duration, for the receive callback to be executed. One way of achieving this is to maintain a container of sockets as a global variable.

Created attachment 3076 [details]
uan-examples.patch

Do we really want to merge all the examples?
The goal was to implement RFC6775 and use 6LoWPAN.

The examples are useful also without 6775.
When 6775 will be merged (I know, I'm late on its review) we can update the examples to use that too.



(In reply to Hossam Khader from comment #9)
> Do we really want to merge all the examples?
> The goal was to implement RFC6775 and use 6LoWPAN.

Created attachment 3077 [details]
uan-examples

Just changing the run time of the experiments, to make sure the energy source depletes.

changeset:   13389:e54f7c46e34f