On Thu, Aug 20, 2015 at 1:07 PM Max Mertens <[email protected]> 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: [email protected] http://www.ual.es/~vruiz tel: +34 950 015711 fax: +34 950 015486
-- Mailing list: https://launchpad.net/~p2psp Post to : [email protected] Unsubscribe : https://launchpad.net/~p2psp More help : https://help.launchpad.net/ListHelp
