On Tue, 2010-11-30 at 21:02 -0500, Hans-Christoph Steiner wrote:
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?)
Martin
I call mrpeach/net canonical not because I believe is it perfect and bugfree, but rather because it is the established, proven way of doing more elaborate networking.
Probably it can be considered established because it has been there for quite some time, nevertheless I've found it hard to use for what I would call 'elaborate' networking right from the beginning. I don't know in what scenario you think it might have an established use. Actually, many protocols that I can think of would be fun to use with [tcpserver] are packet oriented (as opposed to stream oriented). And since TCP is a stream oriented protocol, there is no way [tcpserver] can be directly used as is. Rather one has to make sure while using a packet oriented protocol to correctly create protocol compliant packets from what is received from [tcpserver] from several sockets. It might well be that parts of different packets are received interleaved. Furthermore, the creation iemnet's [tcpserver] was actually driven by issues [mrpeach/tcpserver] is still suffering from (Check my other mail). I hope I could challenge what you call 'established', 'proven' and 'elaborate'.
Its the best option out there. iemnet is just a fork of that with some specific changes. iemnet is very new and not tested as much,
Believe me, it's very well tested.
so it seems a really bad idea to start basing things off of it, like how to package things in Debian, etc. Who knows, perhaps mrpeach/net and iemnet will merge again.
Actually, I'd hope so. From what I can tell, they can be exchanged transparently with the following exceptions:
* The output of the fifth outlet in [tcpserver] is different in iemnet. Since the fifth outlet has been added quite recently in mrpeach and also has changed since, I don't think that would be much of an issue.
* iemnet's object classes don't support sending from file. This is actually a feature not related to networking. Also it can be simply added by patching by using mrpeach's [binfile].
* iemnet's object classes add the port number to the address outlet (which doesn't break mrpeach)
* some performance related settings/methods were removed from iemnet's [tcpserver], simply because they are not necessary (no buffer overflows nor blocking of Pd ever happened with iemnet's [tcpserver] in my tests).
On a side-note: the netpd-server-tcpserver.pd patch mentioned in my earlier post runs with both, mrpeach's and iemnet's [tcpserver]. No other changes are necessary when switching.
Roman