← Back to team overview

p2psp team mailing list archive

Re: NAT Traversal Set of rules implementation

 

On Thu, Aug 20, 2015 at 1:07 PM Max Mertens <max.mail@xxxxxxxxxx> wrote:

> Hi Vicente,
>
>
>
> Which is the time between two consecutive messages?
>
> Currently a message is sent 3 times without a pause in between. This
> avoids blocking the splitter (as would be possible when waiting e.g. 1ms
> between each message), but could lead to network congestion and a higher
> packet loss.
>
>
In the congestion avoiding mechanism implemented in the peers we have used
the chunk cadence like a clock. The idea is to send a message only if a
previous message has been received. The splitter receives chunks from the
source and this could be our clock. It is also true that a new thread in
the splitter increases its complexity, but if you put this code (basically,
a counter that it is incremented each time a new chunk is received from the
source and the sendto(message)) in a thread, the main thread could be as
clean as it is now.


> Ah, now I remember the paragraphs about this technique in the paper. Sadly
> when clustering, the splitter has more load as it sends all data once to
> each cluster.
>
>
Well, any peer can contribute (like a new source). This means that one or
more peers of the team can be a source, and so on.


> Now I finally finished coding, with implementing the reporting of
> currently allocated source ports of incorporated peers behind SYMSP NATs.
> Today I would like to read through the NTS code again and clean it up, add
> comments. For this I have another question about logging and verbosity: It
> seems from the P2PSP code that sometimes 'std.stdout', 'print()' and
> '_print_' is used, debug messages are shown if '__debug__' is set, and some
> messages are colorized.
> Is there some preferred output method, and coloring scheme? Then I will
> apply this to the NTS code as well.
>
>
Yes. We are not very constant with our coding style :-/

No, we haven't decided how to print the information in the console. This
functionality is important for some time and after that, it becomes too
much verbose.

Python provides the logging facility
<https://docs.python.org/2/library/logging.html> (something that you
probably know). Perhaps this is a good moment to rethink this and star
using a tool such that.


> Overnight I will be running final test runs. Are there special networking
> conditions (delay, jitter, loss rate) you would like to have tested? I will
> probably configure 30ms delay ±5ms jitter and 1% packet loss (comparable to
> my home internet), and maybe a harder condition like 10ms delay ±5ms jitter
> and 10% packet loss to compare.
> Then tomorrow morning I will add the result tables to the documentation,
> and send pull requests for the nts and the nts_doc branch, so you can look
> through it tomorrow before merging. Is this ok for you?
>

Perfect. Good work.

Best,
Vi.
-- 
-- 
Vicente González Ruiz
Depto de Informática
Escuela Técnica Superior de Ingeniería
Universidad de Almería

Carretera Sacramento S/N
04120, La Cañada de San Urbano
Almería, España

e-mail: vruiz@xxxxxx
http://www.ual.es/~vruiz
tel: +34 950 015711
fax: +34 950 015486

Follow ups

References