On Wed, 2013-07-03 at 12:56 +0200, Antoine Villeret wrote:
> then I tried udpserver which doesn't work (at least the version in the > pd's SVN) > then I switch to tcpserver and I got a lots of troubles... Things look good as long as you think you only need streams. As soon as you figure out that you need to send packets between your instances of Pd, things get really complex wit [tcpserver].no, I don't really need stream I choose [udpserver] because it's the only server in the iemnet's folder that works yep, it's a stupid reason... I should better try another udpserver somewhere else... :-)
I think iemnet is the only library with a [udpserver] implementation. It doesn't seem to be working and also the help-file reflects that. Actually, a working [udpserver] would be practical when dealing with packets, much more so than a [tcpserver].
> I will try out iohannes version of iemnet and I'll also investigate > those bugs
My _personal_ opinion is that helping fix bugs for iemnet is rather worth effort than for net. I gave up on net, especially on [net/tcpserver] and am exclusively using iemnet. iemnet's design is a bit different in that it puts each socket into its own thread which has some advantages:
* iemnet hardly ever blocks Pd * iemnet is quite fast performance-wise * iemnet hasn't exposed any data integrity issues
cons:
* connection state is not reported correctly (incl. num of connected clients) * is by design more prone to crashes. However, I haven't experienced them for quite a while. I consider it quite stable nowadays
I haven't found a version of [net/tcpserver] that reliably ensures data integrity. Under load I always received mixed up or even lost chunks of data. This was on Linux. Your mileage may vary if you are on Windows, though.
Roman