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 _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
