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