hi martin, hi all
i ve been testing the new netpd-server based on the new [tcpserver]/[tcsocketserver FUDI] now for a while and definitely could solve some problems, but some new ones were introduced.
i found, that the most recent version of [tcpserver] peforms quite bad cpu-wise. this has some side-effects. in netpd, when a certain number of users are logged in (let's say 16), it can happen, that the traffic of those clients makes the netpd-server use more than the available cpu-time. i made some tests and checked, if all messages come through and if messages delivered by the server are still intact. under normal circumstances, there is no problem at all. but under heavy load, when the pd process is demanding more than available cpu time, some messages are corrupted or lost completely; in the worst case the pd process segfaults, at the moment of a client connecting or disconnecting. i guess, this is due to some buffer under- or overrun between pd and the tcp stack, but i don't really know. i wrote a benchmark patch and found out, that not only the new netpd-server patch performs badly, but quite some portion of bad performance comes from the new [tcpserver]. the testpatch compares perfomances of sending data to clients using [tcpserver] and [netserver] from maxlib. the version of [tcpserver] shipped with current pd-extended performs slightly better than [netserver] (tested on OS X and linux). however, the most recent version, that solves the tcp buffer overrun problem, performs ~11 times worse than [netserver]. is that the trade off from solving the other issue? or could this theoretically be improved?
unfortunately, i still don't have a netpd-server running, which can be considered stable. the current one doesn't crash anymore, because clients lost network connection, but it crashes, when there is too much traffic. respectively, it cannot be considered reliable, because it drops messages under certain circumstances.
@code-maintainers is anyone maintaining the code of [netserver] or maxlib in general? this object class still suffers from the 'buffer overrun -> pd hangs' problem. since the same problem was fixed for [tcpserver], it might not be too hard to port that fix to [netserver]. i am not able to dig into c sources, so i wanted to kindly ask here, if someone is interested to do it. [tcpsocketserver FUDI] was meant as a replacement for [netserver] in order to get rid of the pd hangs caused by it. however, now i am not sure anymore, if this approach was a good idea at all, since the overhead from implementing FUDI parsing and stuff in pd instead of in c seems to be enormeous.
roman