Hey Dan
On Sun, 2019-08-11 at 03:49 +0200, Dan Wilcox wrote:
Christoph and I have more or less finished some work that updates Pd's networking and also fixes some bugs and a couple pain points:
Cool. Thank you both!
I did test a few things with patches I just made up (on Ubuntu 18.04), since my network-based patches usually use iemnet. Although, I can't help you out with real-world data, here are some findings:
- IPv6 support
I wasn't able to test yet. I was worried about the future with Pd and networking, but don't have to be now, thanks to you ;-)
- multicast
Works for me, between different computers in the same LAN and also between different software (nc -> Pd, Pd <-> Pd).
- netsend: optional from hostname & port outlet
That's really useful and absolutely necessary when dealing with multiple incoming connections. Only now it is possible to write server- like patches with Pd-vanilla.
- netsend: connectionless UDP, no more connection refused (fire &
forget without having to manually reconnect)
Although the old behavior was "correct" in some sense (it was nitpickingly correct to terminate a link to an endpoint detected not to be existent), I think the new behavior is much more useful. It works well for me, I can shut down the receiving host, restart the software or even replace the software by another listening on the same port, the packets still arrive.
- netreceive: settable timeout which defaults to 10 seconds (no more
super-long frozen Pd)
Definitely an improvement, too. The OS defaults are way too long. The default is good, having it settable even better.
- improved error printing with netsend and netrceive Find Last Error
support
- various small bug fixes (no more polling errors after socket is
closed)
Nice.
One current limitation is that Tcl 8.5 does not have IPv6 support, so the core communication with the GUI remains IPv4.
I wouldn't know why the internal connection should switch to IPv6. My gut feeling is that such things will stay on IPv4 for quite long.
One little thing bugs me in the help file of [netsend] and I just noticed that it was there since at least 0.47: The different modes are labeled 'ASCII' vs. 'binary'. I think 'ASCII' is misleading in that there are semantics in the message format. Spaces have meaning, messages are always terminated by semi-colon. You can't use the 'ASCII' mode for generating arbitrary messages. 'ASCII' suggests you could use it to write valid HTTP requests which you can't. I think 'ASCII' should be re-labeled as 'FUDI', since that it is the protocol the non-binary mode actually uses.
I think these are _very_ valuable improvements for Pd's net objects. I can't think of a reason not to include them. Of course, it would be interesting to get some feedback also from people who actually have patches that heavily use those objects.
Roman