← Back to team overview

p2psp team mailing list archive

Re: NAT Traversal Set of rules implementation

 

Hi Vicente,

On 08/20/2015 11:43 PM, Vicente Gonzalez wrote:
>
>>
>>     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.
Ok, this sounds good. Or to reduce complexity the thread could also
enqueue the messages to be sent, and then send them one after another
with a defined time (e.g. 1ms) in between, so there has to be no
synchronization between receiving chunks and sending packets. I can try
to implement this today in a simple way.

>     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.
Ok, now I understand this. Thanks. :)

>  
>
>     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.
Ok, using the logging classes seems like a good idea, and should provide
easy filtering of the output during debugging.
In the NTS code I used 'print()' in nearly all cases; I'll leave it like
this and add 'if __debug__' statements before the output that is
unimportant for a normal user running P2PSP.

Currently I'm cleaning up the code and adding the test script; the last
test run should be finished in about half an hour, so I'll send the pull
requests then.

Thanks,
Max


Follow ups

References