[PD-dev] split out 'osc' and 'net' from 'mrpeach'?

[Roman Haefeli]

On Sun, 2010-11-28 at 16:17 -0500, Martin Peach wrote:
> On 2010-11-28 15:57, Roman Haefeli wrote:
> > On Sun, 2010-11-28 at 13:38 -0500, Martin Peach wrote:
> >> On 2010-11-28 12:13, Hans-Christoph Steiner wrote:
> >>>
> >>> Hey Martin and all,
> >>>
> >>> Just had a thought: originally everything in the 'mrpeach' folder was
> >>> bundled into a single library, which I think Martin didn't really
> >>> intend. I did it to get Martin's valuable code out there in a kind of
> >>> beta way. Now I think its quite clear that the 'net' and 'osc' sections
> >>> in 'mrpeach' are really the canonical way of doing networking and OSC
> >>> with Pd
> >
> > I'd hesitate to call using  mrpeach/net the 'canonical' way. Last time I
> > checked, there were still issues with many classes, in particular the
> > blocking issue of [tcpsend]/[tcpclient]/[tcpserver] discussed in a
> > plethora of mails. That's also the reason why IOhannes rewrote those and
> > released them as the iemnet library. The classes from iemnet are
> > high-performance and don't suffer from any blocking issue.
> 
> That's another reason they should be in net instead of mrpeach: it seems 
> that having my name on the folder inhibits others from improving the 
> objects, so we end up with multiple parallel incompatible objects, in 
> this case with the same names.
> 
> (And when was the last time you checked?)

Today. I made a little stresstest patch for the netpd-server based on
[tcpserver]. Since I currently don't have a second computer at hand,
it's difficult for me to test for the blocking issue, but I found
another issue. The stresstest client patch sends 1000 messages per
second prefixed with its own socket number, so that the server sends
them back to the client. The client checks, if the message are returned
in order and also if they are valid/have the same content as initially
sent.  It turns out, that although the messages are received in order on
the server, the client seems not to receive some while getting
duplicates of others. Check those logs:

How they are received on the server from the client and how they are
sent back to the client:

print: 6 test 523 eins zwei drei vier fuenf sechs sieben acht neun zehn elf zwoelf dreizehn vierzehn fuenfzehn sechszehn siebzehn
print: 6 test 524 eins zwei drei vier fuenf sechs sieben acht neun zehn elf zwoelf dreizehn vierzehn fuenfzehn sechszehn siebzehn
print: 6 test 525 eins zwei drei vier fuenf sechs sieben acht neun zehn elf zwoelf dreizehn vierzehn fuenfzehn sechszehn siebzehn
print: 6 test 526 eins zwei drei vier fuenf sechs sieben acht neun zehn elf zwoelf dreizehn vierzehn fuenfzehn sechszehn siebzehn
print: 6 test 527 eins zwei drei vier fuenf sechs sieben acht neun zehn elf zwoelf dreizehn vierzehn fuenfzehn sechszehn siebzehn
print: 6 test 528 eins zwei drei vier fuenf sechs sieben acht neun zehn elf zwoelf dreizehn vierzehn fuenfzehn sechszehn siebzehn
print: 6 test 529 eins zwei drei vier fuenf sechs sieben acht neun zehn elf zwoelf dreizehn vierzehn fuenfzehn sechszehn siebzehn
print: 6 test 530 eins zwei drei vier fuenf sechs sieben acht neun zehn elf zwoelf dreizehn vierzehn fuenfzehn sechszehn siebzehn
print: 6 test 531 eins zwei drei vier fuenf sechs sieben acht neun zehn elf zwoelf dreizehn vierzehn fuenfzehn sechszehn siebzehn
print: 6 test 532 eins zwei drei vier fuenf sechs sieben acht neun zehn elf zwoelf dreizehn vierzehn fuenfzehn sechszehn siebzehn
print: 6 test 533 eins zwei drei vier fuenf sechs sieben acht neun zehn elf zwoelf dreizehn vierzehn fuenfzehn sechszehn siebzehn


How they are received by the client:

print: test 523 eins zwei drei vier fuenf sechs sieben acht neun zehn elf zwoelf dreizehn vierzehn fuenfzehn sechszehn siebzehn
print: test 525 eins zwei drei vier fuenf sechs sieben acht neun zehn elf zwoelf dreizehn vierzehn fuenfzehn sechszehn siebzehn
print: test 526 eins zwei drei vier fuenf sechs sieben acht neun zehn elf zwoelf dreizehn vierzehn fuenfzehn sechszehn siebzehn
print: test 527 eins zwei drei vier fuenf sechs sieben acht neun zehn elf zwoelf dreizehn vierzehn fuenfzehn sechszehn siebzehn
print: test 528 eins zwei drei vier fuenf sechs sieben acht neun zehn elf zwoelf dreizehn vierzehn fuenfzehn sechszehn siebzehn
print: test 529 eins zwei drei vier fuenf sechs sieben acht neun zehn elf zwoelf dreizehn vierzehn fuenfzehn sechszehn siebzehn
print: test 529 eins zwei drei vier fuenf sechs sieben acht neun zehn elf zwoelf dreizehn vierzehn fuenfzehn sechszehn siebzehn
print: test 529 eins zwei drei vier fuenf sechs sieben acht neun zehn elf zwoelf dreizehn vierzehn fuenfzehn sechszehn siebzehn
print: test 529 eins zwei drei vier fuenf sechs sieben acht neun zehn elf zwoelf dreizehn vierzehn fuenfzehn sechszehn siebzehn
print: test 529 eins zwei drei vier fuenf sechs sieben acht neun zehn elf zwoelf dreizehn vierzehn fuenfzehn sechszehn siebzehn
print: test 529 eins zwei drei vier fuenf sechs sieben acht neun zehn elf zwoelf dreizehn vierzehn fuenfzehn sechszehn siebzehn
print: test 531 eins zwei drei vier fuenf sechs sieben acht neun zehn elf zwoelf dreizehn vierzehn fuenfzehn sechszehn siebzehn
print: test 533 eins zwei drei vier fuenf sechs sieben acht neun zehn elf zwoelf dreizehn vierzehn fuenfzehn sechszehn siebzehn
print: test 533 eins zwei drei vier fuenf sechs sieben acht neun zehn elf zwoelf dreizehn vierzehn fuenfzehn sechszehn siebzehn

The situation significantly improves when lowering the rate the messages
are sent. However, in an application like netpd it's hard to control the
overall message rate beforehand. 

The same stresstest performed with [iemnet/tcpserver] instead of
[mrpeach/tcpserver] doesn't show any irregularities, even with 5
instances of the stresstest patch running as clients (more can my CPU
not handle | The high CPU load comes from the [tcpserver] object, but
from the fact that FUDI delimiting is done in the byte realm with Pd
objects). 

You find all the patches (netpd-server-tcpserver.pd and stresstest.pd)
on:
https://github.com/reduzent/netpd-server

Roman